Open ColeSiegelTR opened 2 years ago
@ColeSiegelTR Could you please try the following options?
Remove the nextRotationTime
after the initial update. Will an undefined value work for subsequent updates?
Include nextRotationTime
to the ignoreChanges
option. Then, you would also have to refresh the state before each update. Refresh will pull the latest nextRotationTime
value and use it in the update payload.
I'm not yet sure how to solve this on the provider level - but if (1) or (2) works that can inform our thinking here.
Hi @mikhailshilkov
Sorry for the delay in my response. Your option #2
adding the nextRotationTime
to ignoreChanges
worked really well (maybe it should be default behavior for this property?). I didn't realize that was an option, thank you for sharing. I didn't follow what you meant about needing to run refresh
, would that be just if I care about referencing the current nextRotationTime
? Or will I need to run refresh
in order to avoid breaking anything in the next PATCH
request even for unrelated properties? I think because PATCH
requires update masks it should be safe to just ignore this property entirely once it is managed by GCP.
Also in case it helps, I also tried #1
- after commenting out nextRotationTime
an update was still triggered:
colesiegel@TR-C02VD7EGHTD6 repro % pulumi up -v 1
Previewing update (test-bug-repro):
Type Name Plan Info
pulumi:pulumi:Stack bug-repro-test-bug-repro
+- └─ google-native:cloudkms/v1:CryptoKey bucket_key replace [diff: -nextRotationTime]
Resources:
+-1 to replace
1 unchanged
Do you want to perform this update? yes
Updating (test-bug-repro):
Type Name Status Info
pulumi:pulumi:Stack bug-repro-test-bug-repro **failed** 1 error
+- └─ google-native:cloudkms/v1:CryptoKey bucket_key **replacing failed** [diff: -nextRotationTime]; 1 error
Diagnostics:
pulumi:pulumi:Stack (bug-repro-test-bug-repro):
error: update failed
google-native:cloudkms/v1:CryptoKey (bucket_key):
error: error sending request: googleapi: Error 409: CryptoKey projects/projectidxxx/locations/us-east4/keyRings/a206447-us-east4-keyring-test6/cryptoKeys/test-key-id123 already exists.: "https://cloudkms.googleapis.com/v1/projects/projectidxxx/locations/us-east4/keyRings/a206447-us-east4-keyring-test6/cryptoKeys?cryptoKeyId=test-key-id123" map[cryptoKeyId:test-key-id123 keyRingId:a206447-us-east4-keyring-test6 location:us-east4 project:projectidxxx purpose:ENCRYPT_DECRYPT rotationPeriod:86400s]
Resources:
+-1 replaced
1 unchanged
I wanted to note that the update is fixed now with #386. I agree that the nextRotationTime
should be an internal detail that the user doesn't have to worry about, so I'll leave this issue open to track that improvement.
@lblackstone Running into the same issue.
const key = new google-native.cloudkms.v1.CryptoKey("database-key", {
project: args.project,
location: args.region,
versionTemplate: {
algorithm: gcp.cloudkms.v1.CryptoKeyVersionTemplateAlgorithm.GoogleSymmetricEncryption,
protectionLevel: gcp.cloudkms.v1.CryptoKeyVersionTemplateProtectionLevel.Hsm,
},
purpose: gcp.cloudkms.v1.CryptoKeyPurpose.EncryptDecrypt,
keyRingId: keyRing.keyRingId,
rotationPeriod: "7890000s", // 3 months
nextRotationTime: new Date(Date.now() + 86400 * 1000).toISOString(),
}, { parent: this });
This causes the nextRotationTime to be updated every time I run an apply, and I don't want this because we use the pulumi-operator to apply this program. The current behavior would move the rotation time up during every reconciliation, so I guess it would never rotate :). I don't quite get the reason for this property anyway because It's already implied when the key should be rotated via the rotationPeriod. Looking at the cli example here: https://cloud.google.com/kms/docs/rotating-keys#automatic
NEXT_ROTATION_TIME: the timestamp at which to complete the first rotation, for example "2023-01-01T01:02:03". You can omit --next-rotation-time to schedule the first rotation for 7 days from when you run the command. For more information, see [CryptoKey.nextRotationTime](https://cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings.cryptoKeys#CryptoKey.FIELDS.next_rotation_time).
I guess the behavior should be that this property defaults to 7 Days from now and is dropped for every update.
When creating a
CryptoKey
withrotationPeriod
set, it is required to specify thenextRotationTime
However, the initial rotation time needs to be dynamically determined based on the
Date
/rotationPeriod
, while subsequent rotations performed by GCP automatically update thenextRotationTime
.The problem is that the Pulumi resource will store the
nextRotationTime
and attempt to update it on subsequent deployments, it seems like this value shouldn't be tracked by Pulumi? Any suggestions?