+ 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.
* Vendor cloud logging api
* Add logging sink support
* Remove typo
* Set Filter simpler
* Rename typ, typName to resourceType, resourceId
* Handle notFoundError
* Use # instead of // for hcl comments
* Cleanup test code
* Change testAccCheckLoggingProjectSink to take a provided api object
* Fix whitespace change after merge conflict
* Fix bug with CSEK where the key stored in state might be associated with the wrong disk
* preserve original order of attached disks
* use the disk index to figure out the raw key
* Add preemptible as an option to node config
* Check for preemptible in test matching functions
* Move flattenClusterNodeConfig to node_config
* Handle bools properly when comparing in cluster and node pool tests
* Use a supported image_type in cluster tests
* Support views in Terraform.BigQuery
* Add tests for Table with view, and fix existing Table test
* Remove dead code
* run gofmt
* Address comments
* Address review comments and add support for use_legacy_sql
* Force transmission/storage of UseLegacySQL
* Trying to fix tests
* add tests for useLegacySQL
Storage bucket ACLs inherited the behaviour of only updating the fields
that were set in the config file. Terraform should track all the fields
in the resource, whether the user has specified a value for them or not,
and correct any drift that may occur.
This has manifested in an issue and unexpected behaviour in #50, and
this PR restores the expected behaviour.
