Adds support for creating Cloud KMS KeyRing resources #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fix the CI tests we broke with the deprecations for 1.0.0, and update the docs we missed. Also, update the examples.
mrparkers
commented
Sep 29, 2017
| parent := createKmsResourceParentString(config.Project, location) | ||
| keyRingName := createKmsResourceKeyRingName(config.Project, location, name) | ||
|
|
||
| listKeyRingsResponse, err := config.clientKms.Projects.Locations.KeyRings.List(parent).Do() |
There was a problem hiding this comment.
I chose to use List and iterate over the results instead of using Get on the given KeyRing id, because otherwise it would have looked too much like the production code in resourceKmsKeyRingRead
|
Also, I neglected to create a new GCP project and use that during the execution of this test. I'll add this later so these tests won't fill the test project with a bunch of undeletable resources. |
…eprecations 1.0.0 Deprecations, pt 2
* instance templates still use the disk field * more fixes
….0.0_broken_links Fix broken links.
`compute_instance`'s StateVersion was set to 2. Then we released a migration to v3, but never updated the StateVersion to 3, meaning the migration was never run. When we added the migration for disks, we bumped to 4, bypassing 3 altogher. In theory, this is fine, and is expected; after all, some people may have state in version 0 and need to upgrade all the way to 4, so our schema migration function is supposed to support this. Unfortunately, for migrations to v2, v3, and v4 of our schema, the migration _returned_ after each migration, instead of falling through. This meant that (in this case), version 2 would see it needs to be version 4, run the state migration to version 3, then _return_, setting its StateVersion to _4_, which means the migration from 3->4 got skipped entirely. This PR bumps the version to 5, and adds a migration from 4->5 such that if there are still disks in state after 4, re-run 4. This will fix things for people that upgraded to 1.0.0 and had their StateVersion updated without the migration running. I also updated the tests @danawillow wrote to start from state version 2 instead of state version 3, as the state would never be in version 3. I also duplicated those tests, but started them from state version 4 (assuming the migration hadn't run) and verifying that the migration from 4->5 would correct that.
….0.0_migration Fix compute_instance migration bug.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With passing acceptance test