Terraform: genesyscloud_script forces replacement

Genesys Cloud Integrations
1

Hello,

With any update to genesyscloud_script, TF is forcing to replace the object instead of updating it. The replacement is forced even if I simply add a space to the file.

We would expect an update, as we have references by GUID to the existing script, which would no longer work properly as a new object (and therefore ID) is created with the replacement.

Example:

Terraform will perform the following actions:

module.script.genesyscloud_script.CICD_test must be replaced

-/+ resource "genesyscloud_script" "CICD_test" {
~ file_content_hash = "772940cb2a0d4d5e7127d76b8ed2636dd946e519bc4f40d8c2935d71fa56619d" -> "5d6a432f31ea88d8b9b6ef85bb2a12f0d4d69af152a493a48c1fd09099f3bbc3" # forces replacement
~ id = "dd9e4956-df33-411b-ab05-ec5ab287e23d" -> (known after apply)
# (2 unchanged attributes hidden)
}

Plan: 1 to add, 0 to change, 1 to destroy.

Thank you.

2

Hi,

Unfortunately the scripts resource does not support updating a script hence why any change to the properties of the script resource results in the script being recreated. We apologise for the inconvenience and we will update the documentation to be more clear.

Regards,
Declan

3

Thank you for your response.

Would it please be possible to add this functionality?

This makes the genesyscloud_script in Terraform a no-go for us as we would have to look for and update all references to the script ID.

Please advise if there is anything we can do to have this fixed, or if we need to submit a Feature Request or anything like that.

Thanks again.

4

Hi JMackek,

I will chat with the engineer who originally wrote the component. There might be a good reason why we defined this resource to be based on Scripts API behavior. I can't commit to changing the resource behavior until I understand the reasoning behind the design.

Just out of curiosity when you are updating the script ID, where are you being forced to update the script ID (e.g. the flows, queues, etc....)

Thanks,
John Carnell
Director, Developer Engagement

5

Hello,

We are loading scripts dynamically based on a number of conditions, sometimes even configured in datatable_row (AFAIK). Our Dev team makes the assumption of "this is the script ID", and it would take a lot of API calls to make sure we find and replace the script ID everywhere.

On our end, referencing by script name would be another solution, but I'm not sure what it would take or if that would even work in all cases.

That's why the simplest solution (on our end) would be the ability to update existing script (existing ID).

The reason we were looking to add scripts to TF/CICD in the first place was to reduce the number of steps needed during releases, where we currently do all the steps through UI (open, backup, update, publish, test).

Thank you.

6

Hi Jmakacek,

I am still working with my dev team to determine why we set the forceNew on the scripts attribute. One thing you could look at doing in the meantime is running a small script at the end of your Terraform script (post condition) you could look up the script that is created and then update your table with the new script ids.

Are there specific Genesys Cloud configurations that are sensitive to script ids?

Thanks,
John Carnell
Director, Developer Engagement

7

Hi John,

Thank you for your response.

Regarding script IDs, it is my understanding that all object references are by GUID (as far as I'm aware - there are no references by name in the configuration).

When it comes to updating all references through API calls, we already run into issues with API limits for our terraform configuration, so this may work in the short term, but long term this would not work for us as we already have 1000s of objects, and will be adding (1000?) more. This would be extra complicated if objects are split up between multiple projects/repositories and/or Terraform modules.

On this topic, in general, I'm not sure if I can think of a use case where remove-and-create would be the desired outcome when object configuration is updated. Perhaps for object name (we'd still prefer an update), and definitely for Terraform resource name change (we use Terraform rm and import to get around this).

Thank you.

8

Hi Jmakacek,

  1. I talked with the scripting team and my engineering team yesterday. We think we can keep the script IDs stable when you update them. We are targeting our 1.26.0 on November 27th for this fix so I would keep you on the GitHub repository for that release.

  2. Could you provide more detail on the rate limits you said you were hitting with Terraform and scripts? All of our code in Terraform respects 429s and automatically retries on hitting an API rate limit. I am curious because I want to make sure we do not have any bugs lurking around :).

Thanks,
John Carnell
Director, Developer Engagement

9

Hello,

My apologies for a late response. We haven't seen limit errors for a while as we implemented a workaround which seems to be working for now.

To get around API Limits through TF, we ended up implementing a workaround by using terraform -target option: we target specific resources and/or modules depending on what was updated, rather than running Plan/Apply against the whole codebase.

That being said, I am not 100% sure that it was API Limits, only strongly suspect so, as the error message TF would display is:

Error: rpc error: code = Canceled desc = context canceled

It would print hundreds of times and then fail.

Thank you.

10

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.