Kms key bootstrap #2824
Kms key bootstrap #2824
Conversation
It will either grab a well-known key or create a new one in the project that is running the tests. This will allow reuse of KMS keys without needing to create/delete them for all of the new resources that are starting to support KMS integration.
|
This was in response to needing tests for #2772 |
|
Shouldn't this live inside MM? |
|
Ah yeah, it should. I'll merge it upstream if you think the approach is sound. |
|
Super high level question: Why not just require a |
|
Summary of IRL conversation: |
Acceptance tests aren't skipped until the phase inside terraform core that applies the configuration. Thus setup code needs to be also skipped. This could also be moved to the pre-config step but due to variable scoping things that are defined in pre-config aren't accesible later.
| * testing KMS integration with other resources. | ||
| * | ||
| * This will either return an existing key or create one if it hasn't been created | ||
| * in the project yet. The motivation is because keyrings don't get deleted and we |
There was a problem hiding this comment.
This is a really long sentence, can you clean it up a bit?
| * to incur the overhead of creating a new project for each test that needs to use | ||
| * a KMS key. | ||
| **/ | ||
| var SharedKeyRing = "tftest-shared-keyring-1" |
There was a problem hiding this comment.
It's for versioning. I added it for my own testing to make sure that new keys were getting created correctly when the constant changed. I left it because if we need to change it in future we can version bump to 2. I could check if the key regex support a 'v1' syntax.
| } | ||
|
|
||
| if keyRing == nil { | ||
| t.Errorf("Unable to bootstrap KMS key. keyRing is nil!") |
There was a problem hiding this comment.
These two lines can be replaced with a t.Fatalf
| *cloudkms.CryptoKey | ||
| } | ||
|
|
||
| func bootstrapKMSKey(t *testing.T) bootstrappedKMS { |
There was a problem hiding this comment.
I have a slight preference for all this to live in another file, but I could be convinced either way.
There was a problem hiding this comment.
I was thinking it might be better off in a kms specific file or just a 'bootstrapping' file if we decide to use the same approach for project reuse
There was a problem hiding this comment.
Sounds reasonable to me!
|
Duplicated by #2837 |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks! |
ghost
locked and limited conversation to collaborators
Add a method that will bootstrap a KMS keyring
It will either grab a well-known key or create a new one in the project
that is running the tests. This will allow reuse of KMS keys without needing
to create/delete them for all of the new resources that are starting to
support KMS integration.
Goal:
Since it looks like there is a strong push to get KMS support on many different resources in the GCP ecosystem I want to making testing those resources easier. This should help to speed up tests, reduce our project quota burden and simplify tests.