Rename all ID fields to {resource_noun}_id instead of removing them
outright. This means people can still get at the info.
Leave project's id deleted. It has been marked as Removed for months.
I'm fine with cleaning it up before 1.0.0.
Also, update website docs.
Right now we can't create subscription on a topic in a different gcp
project since it assume the project from the subscription. The provider
always create the full topic name string
projects/{project}/topics/{topic} with the received topic property.
Using a regexp we validate if the string is already in
the format projects/{project}/topics/{topic} and if it's the case
we don't wrap it again and take it directly. The original functionality
is maintained but it's possible to specify a different project for the
topic.
* Instantiate the cloudkms client
* Implement Create and Read for the kms key ring resource
* Expose the kms key ring resource
* Create acceptance test for creating a KeyRing, fix read to use KeyRing ID
* Add cloudkms library to vendor
* Address style comments
* Use fully-qualified keyring name in read operation
* Remove call to SetId during read operation
* Set ID as entire resource string
* Spin up a new project for acceptance test
* Use Getenv for billing and org environment variables
* And test and logs around removal from state
* Add comments
* Fixes formatting
* Log warning instead of info
* Use a single line for cloudkms client actions
* Add resource import test
* Add ability to import resource, update helper functions to use keyRingId struct
* Use shorter terraform ID for easier import
* Update import test to use the same config as the basic test
* Update KeyRing name regex to be consistent with API docs
* Add documentation page for resource
* Add KeyRing documentation to sidebar
* Adds unit tests around parsing the KeyRing import id
* Allow for project in id to be autopopulated from config
* Throw error in import if project provider is not provided for location/name format
* Consistent variable names
* Use tabs in resource config instead of spaces
* Remove "-x" suffix for docs
* Set project attribute on import if different from the project config
* Initial support for google service account keys
* Add vendor for vault and encryption
* Add change for PR comment
* Add doc and improvement fo public key management
* adding waiter for compatibility with issue google/google-api-go-client#234
* improvement
* Add test with pgp_key
* Perform doc anf format
* remove test if public_key exists
* Add link on doc
* correct pr
* Make google_service_account resource importable
* Add google_service_account testcase with default project
* Mark google_service_account.project as computed to ensure the project id is always stored in the state, defined in configuration or not. Add corresponding test cases
* Inline variables with single usage
* Replace tabs with spaces in configuration strings
* Ensure service account is not recreated when the default project is explicitely added to the configuration
* camelcase
* disk cleanup
* fix attached disk test
* allow disk sources from name or url
* parse disk source better on read
* update docs
* fix boot disk source url
* Reorder fields in schema for style consistency
* Add reusable ZonalFieldValue
* Fix import and read state from API for compute route
* Generate network link without calling the API
This reverts commit 8ab9d96d25 and revives
the original commit that adds t.Parallel to all acceptance tests. It
turns out test failures were unrelated to this change (rather, they were
related to quota issues).
This reverts commit 42de44592f. It appears
there might be thread-safety issues as panics have started occuring when
parallism is ramped up. Reverting for now while investigating.
`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.
* Add state migration from disk to boot_disk/scratch_disk/attached_disk
* get rid of test for now
* update schema version
* add tests for migration
* fix travis errors
* actually fix travis errors
* fix logic when project is set, also remove some log statements
* add tests for reading based on encryption key and image
* use as much of the image URL as we can for matching on image
* read project from config if it wasn't set in the attribute
* update resolveImage call
+ Make the org_id optional when creating a project. Closes#131
+ Mark org_id as computed to allow for GCP automatically assigning the org.
+ Add an acceptance test for project creation without an organization.
+ Skip TestAccGoogleProject_createWithoutOrg if GOOGLE_ORG is set.
+ Add a folder_id to the google_project resource, optionally
specifying the ID of the GCP folder in which the GCP project should
live.
+ Document how one can provision a project into a folder, and added a
sample configuration to create a project into an existing folder.
* Skip test without org if service account is used
* Support folders/* or id only for the folder id field
The `predefined_acl` test for `storage_object_acl` was failing. This is
because we removed the state-setting portion of the `predefined_acl`
field from `storage_bucket_acl`, and due to what I can only assume is a
copy/paste error, `storage_object_acl` was calling the Read function of
`storage_bucket_acl` instead of its own when using `predefined_acl`.
Updating to use `storage_object_acl`'s Read function makes the tests
pass.
Because we were instantiating a client outside of resource.TestCase, it
was being instantiated even for unit tests, which have no credentials,
causing the unit tests to fail. Sadly, this is the only way I could
figure out how to get a client inside resource.TestCase, which is very
sad making, but works.
When GCS buckets are created, they're created with a set of default
ACLs:
* `OWNER:project-owners-{project_number}`
* `OWNER:project-editors-{project_number}`
* `READER:project-viewers-{project_number}`
Normally, this would be fine, or a minor inconvenience. Terraform could
either delete them itself, or the first apply of a user would overwrite
them.
However, trying to remove the `OWNER:project-owners-{project_number}`
ACL yields an API error that the bucket owner must maintain OWNER access
to the bucket. This breaks things like `terraform destroy`, but also
means any config without that line in it will fail to apply, not just
overwrite the value.
To make matters worse, trying to *add* the
`OWNER:project-owners-{project_number}` ACL to any bucket that already
has it _also_ yields the same error about not being able to remove it.
To get around this, the storage_bucket_acl resource has been updated to
largely ignore _just this_ ACL. It will not try to add it if it already
exists, will not try to remove it at all. This does mean that Terraform
is incapable of removing this ACL from a bucket, but I'm not sure it's
possible to do that with the API, anyways.
Tests were also updated to keep the default ACLs as part of the config,
and to change the email addresses to addresses we actually own. I tried
changing to non-existant hashicorp.com email addresses, but was
rejected; only email addresses that are backed by actual Google accounts
can be used, sadly.
