IBM Cloud Database (ICD) instance creation is not idempotent in 1.68.0 provider

[shemau]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform CLI and Terraform IBM Provider Version

Affected Resource(s)

• ibm_database

Terraform Configuration Files

Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.

The basic example in https://github.com/terraform-ibm-modules/terraform-ibm-icd-elasticsearch is sufficient, with version set to 1.68.0.

Most or all terraform-ibm-icd-* repos appear to identify the issue during PR testing. This blocks all the associate PR pipelines.

Debug Output

Panic Output

Expected Behavior

The expect outcome of terraform apply following a successful and complete apply is for no changes to be present. This behaviour was experience upto an including 1.67.1 of the IBM provider for terraform

Actual Behavior

With IBM provider for terraform 1.68.0, a subsequent apply requests identify an update in place

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following
symbols:
  ~ update in-place
 <= read (data resources)

Terraform will perform the following actions:

  # module.icd_elasticsearch.data.ibm_database_connection.database_connection will be read during apply
  # (depends on a resource or a module with changes pending)
 <= data "ibm_database_connection" "database_connection" {
      + amqps         = (known after apply)
      + analytics     = (known after apply)
      + bi_connector  = (known after apply)
      + cli           = (known after apply)
      + deployment_id = "crn:v1:bluemix:public:databases-for-elasticsearch:us-south:a/abac0df06b644a9cabc6e44f55b3880e:aebb9f8a-adfe-43b0-9849-d45db0f4ba15::"
      + emp           = (known after apply)
      + endpoint_type = "public"
      + grpc          = (known after apply)
      + https         = (known after apply)
      + id            = (known after apply)
      + mongodb       = (known after apply)
      + mqtts         = (known after apply)
      + mysql         = (known after apply)
      + ops_manager   = (known after apply)
      + postgres      = (known after apply)
      + rediss        = (known after apply)
      + secure        = (known after apply)
      + stomp_ssl     = (known after apply)
      + user_id       = "admin"
      + user_type     = "database"
    }

  # module.icd_elasticsearch.ibm_database.elasticsearch will be updated in-place
  ~ resource "ibm_database" "elasticsearch" {
      + connectionstrings       = (known after apply)
        id                      = "crn:v1:bluemix:public:databases-for-elasticsearch:us-south:a/abac0df06b644a9cabc6e44f55b3880e:aebb9f8a-adfe-43b0-9849-d45db0f4ba15::"
        name                    = "steve-elasticsearch"
        tags                    = []
        # (15 unchanged attributes hidden)

        # (3 unchanged blocks hidden)
    }

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

Changes to Outputs:
  ~ certificate_base64 = (sensitive value)
  ~ hostname           = "aebb9f8a-adfe-43b0-9849-d45db0f4ba15.bn2a2uid0up8mv7mv2ig.databases.appdomain.cloud" -> (known after apply)
  ~ port               = 31336 -> (known after apply)

Steps to Reproduce

1. terraform apply
2. terraform apply
3. terraform apply Note: ALL subsequent attempts report the same delta, when selecting yes to apply in the previous attempt

Important Factoids

References

• 0000

[shemau]

@hkantare can this be assigned? It is a regression in a deprecated attribute. The work around of ignoring it is not clean, in so much as it generates messages with all providers stating the attribute is deprecated and remove it. MTIA.

[shemau]

The following warnings are reported when ignoring the attribute:

 ╷
 │ Warning: Redundant ignore_changes element
 │ 
 │   on ../../main.tf line 55, in resource "ibm_database" "etcd_db":   
 │   55: resource "ibm_database" "etcd_db" {
 │ 
 │ Adding an attribute name to ignore_changes tells Terraform to ignore future 
 │ changes to the argument in configuration after the object has been created,
 │ retaining the value originally configured.
 │ 
 │ The attribute connectionstrings is decided by the provider alone and
 │ therefore there can be no configured value to compare with. Including this
 │ attribute in ignore_changes has no effect. Remove the attribute from
 │ ignore_changes to quiet this warning.
 ╵
 ╷
 │ Warning: Deprecated attribute
 │ 
 │   on ../../main.tf line 173, in resource "ibm_database" "etcd_db":  
 │  173:       connectionstrings, # https://github.com/IBM-Cloud/terraform-provider-ibm/issues/5546 
 │ 
 │ The attribute "connectionstrings" is deprecated. Refer to the provider
 │ documentation for details. 
 ╵

[hkantare]

@alexhemard Can some one take look at the priority

[hkantare]

@omaraibrahim Can some one look into this with priority

[omaraibrahim]

@shemau I was able to reproduce the issue you put above and I'm currently working on a fix.

[omaraibrahim]

Hi @shemau! A fix has been merged in the following PR: https://github.com/IBM-Cloud/terraform-provider-ibm/pull/5554

[ocofaigh]

Fix looks good, can we close this issue now