SM: Adding parameters causes breaking change

[kierramarie]

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

Terraform v1.9.2
Provider 1.70.0

Affected Resource(s)

• ibm_sm_service_credentials_secret

Terraform Configuration Files

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

resource "ibm_sm_service_credentials_secret" "service_credentials_secret" {
  count           = var.secret_type == "service_credentials" && var.service_credentials_source_service_hmac == true ? 1 : 0 
  region          = var.region
  instance_id     = var.secrets_manager_guid
  secret_group_id = var.secret_group_id
  name            = var.secret_name
  description     = var.secret_description
  labels          = var.secret_labels
  ttl             = var.service_credentials_ttl
  endpoint_type   = var.endpoint_type

  source_service {
    instance {
      crn = var.service_credentials_source_service_crn
    }
    role {
      crn = "crn:v1:bluemix:public:iam::::serviceRole:${var.service_credentials_source_service_role}"
    }
  }
}

Changes to this -->

resource "ibm_sm_service_credentials_secret" "service_credentials_secret" {
  count           = var.secret_type == "service_credentials" && var.service_credentials_source_service_hmac == true ? 1 : 0 
  region          = var.region
  instance_id     = var.secrets_manager_guid
  secret_group_id = var.secret_group_id
  name            = var.secret_name
  description     = var.secret_description
  labels          = var.secret_labels
  ttl             = var.service_credentials_ttl
  endpoint_type   = var.endpoint_type

  source_service {
    instance {
      crn = var.service_credentials_source_service_crn
    }
    role {
      crn = "crn:v1:bluemix:public:iam::::serviceRole:${var.service_credentials_source_service_role}"
    }
    # Adding this parameter causes a destroy to existing resources
    parameters = {
      "HMAC" : var.service_credentials_source_service_hmac
    }
  }
}

Debug Output

Panic Output

Expected Behavior

User should be able to add the parameters section and have the provider update the existing resources without deleting.

Actual Behavior

When adding the parameters section with the HMAC value will cause previously existing resources to be destroyed and recreated, causing a breaking change.

Steps to Reproduce

1. terraform apply on first block
2. Apply change to block
3. terraform apply to updated code

Important Factoids

References

• #0000

[IdanAdar]

Secrets Manager supports only what the IBM Cloud resource controller supports for resource keys ("service credentials"), and updating an existing one is not a supported feature (by resource controller).

If you want to add a customization to a resource key, like HMAC, you need to do this on creation time. Any change afterwards is not permitted.

To confirm this outside of Terraform, manually create a resource key in eg Databases for PostgreSQL and you will not be able to update it after it was created.

So my understanding is that this report is invalid.

[ocofaigh]

@IdanAdar Actually we are not looking to change the service credential. In the ibm_sm_service_credentials_secret resource, we were not passing any parameters (meaning the credential type was defaulting to not be HMAC type). And in the newly proposed code, we are looking to set "HMAC" : false. This is causing a destroy and recreate even though the credential would get re-created the exact same way.
I understand that the resource controller thinks there is now parameters to pass and hence thinks it needs to recreate here, but there might be something that could be done in the provider to prevent this?
We will have to add a workaround in our module to prevent a breaking change, but would be nicer if provider code handled it.