kms_key_v1: Please check state before trying to create a key

[rramge]

Terraform provider version

Terraform v1.3.0-alpha20220608
on linux_amd64
+ provider registry.terraform.io/hashicorp/random v3.3.2
+ provider registry.terraform.io/opentelekomcloud/opentelekomcloud v1.29.9

Affected Resource(s)

opentelekomcloud_kms_key_v1

Terraform Configuration Files

module "kms" {
  source = "../modules/terraform-opentelekomcloud-kms"

  kms_keys = {
    key1 = { alias = "test" }
    key2 = { alias = "test-2", description = "A test key", is_rotation_enabled = true, rotation_interval = 90 }
  }
}

resource "opentelekomcloud_kms_key_v1" "this" {
  for_each = var.kms_keys != null ? var.kms_keys : {}

  key_alias = each.value["alias"]
  key_description = each.value["description"]
  realm = each.value["realm"]
  pending_days = each.value["pending_days"]
  is_enabled = each.value["is_enabled"]
  rotation_interval = each.value["rotation_interval"]
  rotation_enabled = each.value["is_rotation_enabled"]
  tags = var.tags
}

Debug Output/Panic Output

module.kms.opentelekomcloud_kms_key_v1.this["key2"]: Still creating... [10s elapsed]
module.kms.opentelekomcloud_kms_key_v1.this["key1"]: Still creating... [10s elapsed]
╷
│ Error: error waiting for key (f043636f-79d9-4fc0-9d5d-8f491dc13065) to become ready: unexpected state '4', wanted target '2'. last error: %!s(<nil>)
│ 
│   with module.kms.opentelekomcloud_kms_key_v1.this["key2"],
│   on ../modules/terraform-opentelekomcloud-kms/main.tf line 1, in resource "opentelekomcloud_kms_key_v1" "this":
│    1: resource "opentelekomcloud_kms_key_v1" "this" {
│ 
╵
╷
│ Error: error waiting for key (b6654ceb-3325-4d75-ae91-3e37be5e9538) to become ready: unexpected state '4', wanted target '2'. last error: %!s(<nil>)
│ 
│   with module.kms.opentelekomcloud_kms_key_v1.this["key1"],
│   on ../modules/terraform-opentelekomcloud-kms/main.tf line 1, in resource "opentelekomcloud_kms_key_v1" "this":
│    1: resource "opentelekomcloud_kms_key_v1" "this" {
│ 

Steps to Reproduce

1. terraform apply
2. terraform destroy
3. terraform apply

Expected Behavior

After a destroy, another apply on the same terraform code should work.

Actual Behavior

During the destroy, the kms resource gets removed from the state, even though it still exists in OTC for a minimum of 7 and a maximum of 1096 days. During this period, which in production environments can pretty much effectively feel like "forever", other applyruns will loead into this error since the KMS is within OTC in the state "Pending deletion".

The only workaround on terraform level which I see at the moment would be appending random values to the key_alias to make the keys effectively unique, but this is visible for the customer and thus pretty ugly.

So, to avoid breaking customer's production environment, I see two possibilities:

1. (Preferred) The provider should check if a key already exists, and if the state of the kms key is "Pending deletion" the creation should be skipped and optionally a Warning be generated on stdout. Or any other kind of error handling which seems more appropriate. Other cloud providers like Oracle already implement this in the backend and check this during refresh in the planning stage, so it should somehow be possible here, too I think.

2. The quick & dirty solution which comes to my mind would be the introduction of a display_name and turning the key_alias unique.

Important Factoids

References

[anton-sidelnikov]

@rramge Hi, we can add smth like "desired_state" option and reenable the key if it exist (https://docs.otc.t-systems.com/en-us/api/kms/kms_02_0016.html)

[anton-sidelnikov]

Will continue after: opentelekomcloud/gophertelekomcloud#369

[rramge]

Sounds okay to me. Important thing is that a "terraform apply" does not lead into an error, and re-enabling the key would work.

[anton-sidelnikov]

Released, please check.

[rramge]

Released, please check.

You did something, yes, but the problem is still not solved. 'terraform apply' still breaks, the given example is still valid.

It's nice you added a desired_state flag or something, but you also need to validate it and act accordingly during the apply or update phase.

Notable difference is, that now even a manual "terraform import" doesn't work anymore:

╷

│ Error: Cannot import non-existent remote object
│ 
│ While attempting to import an existing object to
│ "module.kms.opentelekomcloud_kms_key_v1.this[\"key1\"]", the provider detected that no
│ object exists with the given id. Only pre-existing objects can be imported; check that
│ the id is correct and that it is associated with the provider's configured region or
│ endpoint, or use "terraform apply" to create a new remote object for this resource.
╵

[anton-sidelnikov]

@rramge Did you add allow_cancel_deletion=true key into your code?

[rramge]

@anton-sidelnikov

I was not aware of allow_cancel_deletion, it's not in the documentation (yet). But now I am, so I hardcoded it in the module.

Effect is that it works with key1 in the following example, but not with key2.

module "kms" {
  source = "../modules/terraform-opentelekomcloud-kms"

  kms_keys = {
    key1 = { alias = "test" }
    key2 = { alias = "test-2", description = "A test key", is_rotation_enabled = true, rotation_interval = 90 }
  }
}

This leads to a follow-up error: {"error":{"error_msg":"The rotation state of key is not disabled.","error_code":"KMS.2901"}}.

[anton-sidelnikov]

Depends-on: #1821

[anton-sidelnikov]

@rramge Please check on new version

[rramge]

@anton-sidelnikov I tested with 1.30.1 and it looks good now.

Thank you very much :-)