Adding kms_config to a vpc cluster triggers cert update for unclear reasons

qrilka commented 3 years ago

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 -v
Terraform v0.14.6
+ provider registry.terraform.io/ibm-cloud/ibm v1.23.2

Your version of Terraform is out of date! The latest version
is 0.15.3. You can update by downloading from https://www.terraform.io/downloads.html

Affected Resource(s)

ibm_container_vpc_cluster
ibm_certificate_manager_order

Terraform Configuration Files

I was adding kms_config to k8s_cluster using

  kms_config {
    instance_id = ibm_resource_instance.kp.guid
    crk_id      = ibm_kp_key.k8s_key.key_id
  }

Previously enabling KMS was done using IMB Cloud CLI

Expected Behavior

KMS config gets updated for the cluster resource

Actual Behavior

TF plan insists on recreating ibm_certificate_manager_order resource saying that issuance_info forces replacement:

      ~ issuance_info                   = {
          - "ordered_on" = "1618403611429"
          - "status"     = "valid"
        } -> (known after apply)

Steps to Reproduce

Unfortunately I don't have a minimal reproduciton scenario at the moment

qrilka commented 3 years ago

In this particular case I just applied the change including certificate reorder.

kavya498 commented 3 years ago

@qrilka , Looks like issuance_info is not resulting force creation of order

 ~ issuance_info                   = {
          - "ordered_on" = "1618403611429"
          - "status"     = "valid"
        } -> (known after apply)

check if certificate_manager_instance_id or domains are been changed.. change in these two attributes can only result in forcenew replacement of cms order resource

qrilka commented 3 years ago

@kavya498 that was my first thought also but the change shown above was the only one and when I comment it out TF plan shows no changes.

kavya498 commented 3 years ago

Can you share your plan output and template

qrilka commented 3 years ago

I'm not sure what "template" is but here are the output and the related parts of TF code - https://gist.github.com/qrilka/4e576b41f1e2579cdb93c02f50a0eefa

kavya498 commented 3 years ago

looks like forcereplacement is happening due to ~ certificate_manager_instance_id = "crn:v1:bluemix:public:cloudcerts:us-south:a/XXXX:c8fd61fa-9a4f-45b7-8d53-8fdc528b46e4::" -> (known after apply) # forces replacement

This attribute is showing a diff because resource_instance datasource is refreshing
Resource_instance datasource is refreshing as it depends on cluster and cluster is having some changes..

We suggest you to not use depends_on on a datasource.

qrilka commented 3 years ago

Oh, thanks that makes sense. Removing depends_on resolves this problem but it will remove the dependency which is needed because of cert manager autocreation.

qrilka commented 3 years ago

In any case this looks to be solved. Thank you. Closing.

qrilka commented 3 years ago

@kavya498 I've tried commenting out depends_on on a different env (with the same code) and cert replacement is still present in the plan so I'm not convinced that it is the reason

kavya498 commented 3 years ago

can you share the plan and tf files for new env?

qrilka commented 3 years ago

The plan is https://gist.github.com/qrilka/ebc65736d1069ce8974d95e5c8849ab5 and the files are basically the same with depends_on commented out and some orthogonal changes

kavya498 commented 3 years ago

@qrilka Looks like data source is trying refresh again Plan should not see any change in resource_instance data source.. Is there any dependency on that data source or are you changing anything? and what do you mean by different env?

qrilka commented 3 years ago

The same code gets deployed to different environments (dev/staging) in different resource groups. No other changes. We applied this so won't plan to dig into this further, feel free to close if you see it as necessary. In any case thanks for spending your time on this.

kavya498 commented 3 years ago

Closing this issue.. Thanks.

IBM-Cloud / terraform-provider-ibm