* fix service account key data source name
* switch id to name
* update docs
* doc format
* fixes for validation and tests
* last fixes for service account key data source
Previously, we were only setting source images for the disks in instance
templates if they weren't set in the config. Instead, let's just always
set them. This fixes our test failures about self_links not matching
names. Also, relative links are safer than just image names, as
Terraform wouldn't notice if another project's image of the same name
got used instead of your project's.
Also fix the setting of tags and tag fingerprints to always set, even if
to the empty value, to fix the tests.
* test empty authorized masters' cidr_blocks
When the `cidr_block` isn't simply blank but contains an empty list as in
```
master_authorized_networks_config {
cidr_blocks = []
}
```
a panic occurs looking something like
```
goroutine 26 [running]:
github.com/terraform-providers/terraform-provider-google/google.expandMasterAuthorizedNetworksConfig(0x15a4f80, 0xc4202586e0, 0x21)
/tmp/GOPATH/src/github.com/terraform-providers/terraform-provider-google/google/resource_container_cluster.go:1355 +0x4f2
github.com/terraform-providers/terraform-provider-google/google.resourceContainerClusterCreate(0xc420146a80, 0x16b1800, 0xc4200b8000, 0x0, 0x0)
/tmp/GOPATH/src/github.com/terraform-providers/terraform-provider-google/google/resource_container_cluster.go:520 +0x2848
github.com/terraform-providers/terraform-provider-google/vendor/github.com/hashicorp/terraform/helper/schema.(*Resource).Apply(0xc420495490, 0xc420341310, 0xc4202582c0, 0x16b1800, 0xc4200b8000, 0x1, 0xc42024eae0, 0xc4201e3650)
/tmp/GOPATH/src/github.com/terraform-providers/terraform-provider-google/vendor/github.com/hashicorp/terraform/helper/schema/resource.go:227 +0x364
github.com/terraform-providers/terraform-provider-google/vendor/github.com/hashicorp/terraform/helper/schema.(*Provider).Apply(0xc4204c6700, 0xc4203412c0, 0xc420341310, 0xc4202582c0, 0x14ee1441a000, 0x0, 0x18)
/tmp/GOPATH/src/github.com/terraform-providers/terraform-provider-google/vendor/github.com/hashicorp/terraform/helper/schema/provider.go:283 +0xa4
github.com/terraform-providers/terraform-provider-google/vendor/github.com/hashicorp/terraform/plugin.(*ResourceProviderServer).Apply(0xc4202d7c40, 0xc42035de80, 0xc42025c160, 0x0, 0x0)
/tmp/GOPATH/src/github.com/terraform-providers/terraform-provider-google/vendor/github.com/hashicorp/terraform/plugin/resource_provider.go:527 +0x57
reflect.Value.call(0xc4203feae0, 0xc42000e038, 0x13, 0x19e88a8, 0x4, 0xc42015ff20, 0x3, 0x3, 0xc420047ee8, 0xc4204c6798, ...)
/usr/local/go/src/reflect/value.go:434 +0x905
reflect.Value.Call(0xc4203feae0, 0xc42000e038, 0x13, 0xc420047f20, 0x3, 0x3, 0xc400000001, 0x0, 0x0)
/usr/local/go/src/reflect/value.go:302 +0xa4
net/rpc.(*service).call(0xc420418600, 0xc42007c140, 0xc42001e798, 0xc4200c4000, 0xc4202d6c40, 0x1557f80, 0xc42035de80, 0x16, 0x1557fc0, 0xc42025c160, ...)
/usr/local/go/src/net/rpc/server.go:381 +0x142
created by net/rpc.(*Server).ServeCodec
/usr/local/go/src/net/rpc/server.go:475 +0x36b
```
which we trigger by altering the first step to contain the HCL notation
for an empty list instead of simply an empty string.
In order to accomplish this, the tests had to be modified to accept an
emptyValue string as well which contains the content of the
`emptyValue` string when the cidrBlocks array is empty. This maintains
the old behavior of the original tests when `emptyValue` is an empty
string, while also facilating differing behavior for the new testcase by
setting `emptyValue` to whichever string we want to test instead. I
don't think this is very clean, but I guess it's pragmatic enough.
I'll hear if this is a thorn in the side to someone 😏.
* avoid panic on cidr_block type assertion
This is basically the fix. Since the value can be nil, we want to ensure
we handle a failure during the assertion since we know that asserting
`nil` conforms to `map[string]interface{}` will cause a run-time panic.
* flatten to config on empty list for cidr_blocks
since an empty list for cidrBlocks constitutes valid input, one should
return a map containing an empty list for the cidr_blocks field instead
of a nil value.
The nil value is only appropriate when the input Config is also nil.
* Update google_container_cluster master_auth username and password without recreation of cluster, using setMasterAuth method
* Add tests to update and disable master_auth password and username values
Fixes#1702.
@chrisst I'm putting you as a reviewer, but no rush. Feel free to ask as many questions as you have! Also feel free to offer suggestions 😃 (or just say it's perfect as-is, that works too)
We had a bad type coercion in the code to update container cluster
resource labels. This fixes the coercion.
We didn't notice this because there was no test exercising the update
code path. I've added the test, which reproduced the panic before this
PR was applied and passes successfully now that the coercion is fixed.
Images now have a licenses field, which lets users specify licenses to
use on an image. But official images already have licenses on them, adn
so Terraform is reading those as a diff. To preserve backwards
compatiblity and avoid a breaking change that would require all
`google_compute_image` users to update their configs, I've set the field
to computed. This means that if no licenses are set in the config, there
can be licenses in the config without prompting a diff. Obviously, this
isn't ideal, as it means you can't ever remove all the licenses from an
image, but I think the benefits here outweigh the drawbacks.
In testing an upcoming `google_compute_region_disk` resource, I had to make these changes. Checking them in separately so that when the magician runs, these changes will already be a part of TF.
Currently, the rolling-update API expects a PUT (regionInstanceGroupManager.update())
instead of a PATCH (regionInstanceGroupManager.patch()) call, so immediate rolling updates
(as specified with `update_strategy = "ROLLING_UPDATE"``) are never triggered:
```
[DEBUG]: ---[ REQUEST ]---------------------------------------
[DEBUG]: POST /compute/beta/projects/mycompany-myapp-staging/regions/europe-west3/instanceGroupManagers/myapp-server/setInstanceTemplate?alt=json HTTP/1.1
....
[DEBUG]: ---[ RESPONSE ]--------------------------------------
...
[DEBUG]: "warnings": [
[DEBUG]: {
[DEBUG]: "code": "FIELD_VALUE_OVERRIDEN",
[DEBUG]: "message": "Update policy type was set to OPPORTUNISTIC. Please use regionInstanceGroupManager.update() to preserve the policy."
[DEBUG]: }
```
refs:
https://cloud.google.com/compute/docs/reference/rest/beta/instanceGroupManagers/patchhttps://cloud.google.com/compute/docs/reference/rest/beta/instanceGroupManagers/updateFix#1506
This was done as its own resource as suggested in slack, since we don't have the option of making all fields Computed in google_compute_instance. There's precedent in the aws provider for this sort of thing (see ami_copy, ami_from_instance).
When I started working on this I assumed I could do it in the compute_instance resource and so I went ahead and reordered the schema to make it easier to work with in the future. Now it's not quite relevant, but I left it in as its own commit that can be looked at separately from the other changes.
Fixes#1582.
When using predefined storage ACLs, you'd get a permadiff, because the
role_entities list was computed, but was never set in state. So it would
be read as empty in the config, and not present in state, so Terraform
would want to pull it down and sync it. This is probably, technically
speaking, a bug in Terraform, but we can work around it by just setting
role_entities to an empty value on every read.
Hypothetically fixes#1643.
@thomasriley, are you able to patch this change into your provider to see if it fixed the problem? I haven't been able to get a working repo so I haven't verified the fix yet.
Move from using qa.test.com, a domain we don't own, to qa.tf-test.club,
a domain we do own, so the domain validation doesn't cause our tests to
fail anymore.
Add a CustomDiff function to storage bucket ACLs that will ignore a diff
if the config and state have the same role_entities, even if they're in
a different order.
Fixes#1525.
Commit 8f31fec introduced a bug for the 'service_account_key' resource
where it required a project be set either in the provider or in the
resource for 'service_account_key', but a project isn't required if the
service account is a service account fully qualified name or a service
account email.
This PR relaxes the requirement that a project needs to be set for the
'service_account_key' resource, 'service_account' datasource and
'service_account_key' datasource, but will error if we try to build a
fully qualified name from a service account id when no project can be
found.
This also cleans up 'serviceAccountFQN' so it is slightly easier to
follow and return an error if there is no project but we need one to
build the service account fully qualified name.
Fixes: #1655
Added node config 'disk_type' which can either be 'pd-standard' or
'pd-ssd', if left blank 'pd-standard' will be the default used by google
cloud.
Closes: #1656
## What
As well as https://github.com/terraform-providers/terraform-provider-google/pull/1282 , make `resource_container_node_pool` importer accept `{project}/{zone}/{cluster}/{name}` format to specify the project where the node pool belongs to actually.
## Why
Sometimes I want to import container pool in different project from default SA's. However, currently there is no way to specify project the target node pool belongs to, Terraform tries to retrieve node pool from SA's project, then it fails due to `You cannot import non-existent resources using Terraform import.` error.
As discussed in #1326, we're not going to remove name_prefix for
compute_ssl_certificate, because it makes the common use case more
ergonomic by a good amount, and the only cost is it's harder to maintain
the autogenerated code, and we've decided the benefits outweigh the
costs in this circumstance.
* Allow using in repo configuration for cloudbuild trigger
Cloudbuild triggers have a complex configuration that can be defined
from the API. When using the console, the more typical way of doing this
is to defined the configuration within the repository and point the
configuration to the file that defines the config.
This can be supported by sending the filename parameter instead of the
build parameter, however only one can be sent.
* Acceptance testing for cloudbuild trigger with filename
Ensure that when a cloudbuild repo trigger is created with a filename,
that filename is what actually ends up in the cloud.
* Don't specify "by default" in cloudbuild-trigger.
The docs shouldn't say that "cloudbuild.yaml" is used by default. There
is no default from the APIs, but the console suggest using this value.
Just say it's the typical value in documentation.
No longer ForceNew when adding an App Engine application to a project,
when modifying the auth domain, modifying the serving status, or
modifying the feature settings.
* Use errwrap to retain original error
* Use built-in Page function, only return names when listing services
This removes the custom logic on pagination and uses the built-in Page function in the SDK to make things a bit simpler. Additionally, I added a field filter to only return service names, which drastically reduces the size of the API call (important for slow connections, given how frequently this function is executed).
Also added errwrap to better trace where errors originate.
* Add helper function for diffing string slices
This just looked really nasty inline
* Batch 20 services at a time, handle precondition failed, better errwrap
This commit does three things:
1. It batches services to be enabled 20 at a time. The API fails if you try to enable more than 20 services, and this is documented in the SDK and API. I learned this the hard way. I think Terraform should "do the right thing" here and batch them in series' of twenty, which is what this does. Each batch is tried in serial, but I think making it parallelized is not worth the complexity tradeoffs.
2. Handle the precondition failed error that occurs randomly. This just started happened, but it affects at least two APIs consistently, and a rudimentary test showed that it failed 78% of the time (78/100 times in an hour). We should fix this upstream, but that failure rate also necessitates (in my opinion) some mitigation on the Terraform side until a fix is in place at the API level.
3. Use errwrap on errors for better tracing. It was really difficult to trace exactly which error was being throw. That's fixed.
* Updates from code review
* Add basic update for `google_kms_crypto_key` resource
Prior to this commit, any changes to `rotation_period` would
force a new resource as no `Update` was defined for the resource.
This commit introduces a basic `Update` through calling the
`Patch` service method. It only modifies the `rotation_period`,
and `next_rotation_time` at the moment, but this is reflective
of what is "allowed" on https://console.cloud.google.com/security/kms.
* Remove unused `Purpose` value in `CryptoKey`
We are only patching the `rotation_period`, and `next_rotation_time`,
so that value will not be affected.
* nit: format `Patch` operation to be in a single line
* Extend `TestAccKmsCryptoKey_rotation` test steps
- Test change in rotation period
- Test removal of rotation period
* Do not parse `NextRotationTime` if it is not set
* remove ForceNew: false
When creating a trigger by using the project defined in the schema we
enforce that the repo must be in that same project. We should be looking
at the project defined in the trigger_template data and falling back to
that first project if not found.
Closes: #1555
When enabling services, after the waiter returns, list the enabled
services and ensure the ones we enabled are in there. If not, retry. May
not always resolve#1393, but should help. Unfortunately, the real
answer is probably either:
1. For us to try and get the API updated to only return the waiter when
the service will consistently be available. I don't know how feasible
this is, but I'm willing to open a ticket.
2. For us to build retries into ~all our resources to retry for a set
amount of time when a service not enabled error is returned. This would
greatly slow down the provider in the case of the service legitimately
not being enabled, but is how other providers handle this class of
problem.
Unfortunately, due to the eventual consistency at play, this is a hard
issue to reproduce and prove, though it matches with my
experience--while testing this patch, one of the tests failed with the
error that the serviceusage API hadn't been enabled, but only on step 4
of the test, when calls had already succeeded. Which suggests eventual
consistency, to me. Regardless, this patch shouldn't _hurt_ and should
mostly be an imperceptible change to users, and should make instances
like #1393 less likely.
* vendor service usage api
* use serviceusage api instead of servicemanagement for project services
* add bigquery-json to test
* add import for project service
* add serviceusage_operation.go
When reading a project, both App Engine and Billing would fail if
_neither_ the default project the provider was configured with nor the
project being targeted had the App Engine Admin or Billing APIs
(respectively) enabled. We didn't catch this because our source project
obviously has both enabled.
This fixes the matter by checking the error returned from each of those,
and if it looks like an API not enabled error, logging it at warning
level instead of returning it as an error, which will let the read
proceed as usual.
IAP has no reasonable support policy, because PATCH is broken, and IAP
must be configured with an OAuth2 client ID and secret that belongs to
the project the app is associated with. There's no programmatic way to
create Clients. But we create the project and the app at the same time,
and we can't update because PATCH is broken. So this just drops IAP. It
also forces all our updates to ForceNew, because we can't update.
Also, adds more test coverage and docs, and fixes import by not relying
on the config for setting app engine info in state.
* Revert "Merge pull request #1434 from terraform-providers/paddy_revert_beta"
This reverts commit 118cd71201, reversing
changes made to d59fcbbc59.
* add ConvertSelfLinkToV1 calls to places where beta links are stored
Fix a panic in our test that is caused by a ListPolicy being nil. I
assume, but cannot verify, that this is an API change in that it may now
send back a nil listpolicy if a default is used.
Add the `enable_flow_logs` field to our subnetwork resource, so we can
specify whether [flow logs][1] should be enabled in Terraform configs.
Note that this behavior isn't explicitly documented yet, but it has made
it into the beta API client.
[1]: https://cloud.google.com/vpc/docs/using-flow-logs
This PR also switched us to using the beta API in all cases, and that had a side effect which is worth noting, note included here for posterity.
=====
The problem is, we add a GPU, and as per the docs, GKE adds a taint to
the node pool saying "don't schedule here unless you tolerate GPUs",
which is pretty sensible.
Terraform doesn't know about that, because it didn't ask for the taint
to be added. So after apply, on refresh, it sees the state of the world
(1 taint) and the state of the config (0 taints) and wants to set the
world equal to the config. This introduces a diff, which makes the test
fail - tests fail if there's a diff after they run.
Taints are a beta feature, though. :) And since the config doesn't
contain any taints, terraform didn't see any beta features in that node
pool ... so it used to send the request to the v1 API. And since the v1
API didn't return anything about taints (since they're a beta feature),
terraform happily checked the state of the world (0 taints I know about)
vs the config (0 taints), and all was well.
This PR makes every node pool refresh request hit the beta API. So now
terraform finds out about the taints (which were always there) and the
test fails (which it always should have done).
The solution is probably to write a little bit of code which suppresses
the report of the diff of any taint with value 'nvidia.com/gpu', but
only if GPUs are enabled. I think that's something that can be done.
This PR does a few things to the User-Agent header:
1. It puts Terraform/(version) first, since that's the way the RFC
expects it
2. It removes the goos and goarch data, although I could be convinced to
put it back in, I don't see what value it's providing
3. Moves directly to consuming the version package (which is the comment
above the function previously being called)
This simply adds the specification for operation timeouts, and sets
sane defaults. In testing against specific regions, creation of SQL
databases would fluctuate between 7-14 minutes against us-east1. As
such, a 15m creation threshold is recommended for this. Update and
Delete operations will adhere to 10m timeouts.
This follows a similar format as #1309.
* escape the folder name (in case of spaces, etc)
* add test case for folder with space
* add missing args
* make separate tests for each folder test, get folder name length under API limits
* further abstract out the resource name to prevent test collisions
* workaround multiple results returning for a given query by looping over return
* split test cases into separate funcs
* adding google folder data source with get by id, search by fields and lookup organization functionality
* removing search functionality
* creating folders for each test and updating documentation with default values
* Add support for regional GKE clusters in google_container_cluster:
* implement operation wait for v1beta1 api
* implement container clusters get for regional clusters
* implement container clusters delete for regional cluster
* implement container clusters update for regional cluster
* simplify logic by using generic 'location' instead of 'zone' and 'region'
* implement a method to generate the update function and refactor
* rebase and fix
* reorder container_operation fns
* cleanup
* add import support and docs
* additional locations cleanup
* Updates the default GKE legacy ABAC setting to false
* Updates docs for container_cluster
* Update test comments
* Format fix
* Adds ImportState test step to default legacy ABAC test
* Add time partitioning field to google_bigquery_table resource
* Fix flatten time partitioning field to google_bigquery_table resource
* Add resource bigquery table time partitioning field test
* Move resource bigquery table time partitioning field test to basic
* Add step to check that all the fields match
* Mark resource bigquery table time partitioning field as ForceNew
* Add time partitioning field test to testAccBigQueryTable config
* Updated google.golang.org/api/container/v1beta1
* Added support for private_cluster and master_ipv4_cidr
This is to implement #1174. See
https://groups.google.com/forum/#!topic/google-cloud-sdk-announce/GGW3SQSANIc
* Added simple test for private_cluster and master_ipv4_cidr
* Review replies
* Added some documentation for private_cluster
This updates the organization policy tests to be run sequentially,
instead of in parallel, as they share a resource that they're modifying.
It also updates them to use a separate organization than the one all our
other tests are running in, which prevents other tests from failing
because they're run in parallel to the organization policy changing
under them.
* add util for handling wrapped/raw google api errors
* add 404 error handling to shared iam files
* fix errwrap calls in iam files
* fix import
* remove newlines, clear ID for removed state in iam binding
* move setid calls back
* Revert "move setid calls back"
This reverts commit 0c7b2dbf92aff33dac8c5beb95568c2bc86dd7de.
* add update support for pod security policy
* update test
* add comment about updates
PR #1217 mistakenly updated the Set logic when flattening backends,
which caused some cascading errors and wasn't strictly necessary to
resolve the issue at hand. This backs out those changes, and instead
makes the smallest possible change to resolve the initial error, by
separating the logic for flattening regional backends from the logic for
flattening global backends.
We had several calls to `d.Set` that returned errors we weren't
catching, that turning on the panic flag for the tests caught. This PR
addresses them, and fixes the one test that was not safe to run in
parallel because it relied on a hardcoded name being unique.
This is largely just removing calls to `d.Set` for fields that don't
exist in the Schema, fixing how Sets get set, correcting typos, and
converting types.
We have a set of constraints we apply to our organization as part of a
test for the organization policy functionality. This can get stuck from
quota issues, or it can run in parallel to other tests. The policy
currently limits the projects that images can be used from to the
project running the test, but a lot of our tests use images from the
debian-cloud project. This just updates the policy to allow debian-cloud
images to be used, too, so even if the policy doesn't properly get
cleaned up or if it runs in parallel with other tests, our tests are
still within the policy.
The real fix for this is to set up a separate org for testing, so we're
not modifying the test environment under running tests, but that'll take
a bit more time, so this is the patchfix until that can happen.
Managed zone tests are failing because we're attempting to use the naked
domain as the managed zone, when it's already being managed by GCP. By
making a subdomain the managed zone, we avoid this problem.
* move setid calls back
* add support for pod security policy
* pod security policy docs
* Revert "move setid calls back"
This reverts commit 0c7b2dbf92aff33dac8c5beb95568c2bc86dd7de.
* cleanup
* remove comments about disabling update
* add extra wait for storage bucket object deletion
* make timeout for object deletion 5 minutes, make it succeed 3 times
* delete the cluster before deleting the bucket
* deprecate delete_autogen_bucket
* improve deprecation message
Exposes existing `google_compute_backend_service` as data sources.
This addresses #149 .
This allows, for instance, to collect a backend service's self_link and
use it from an other workspace/tfstate, sharing most of the
loadbalancers definition.
* add import helpers for generated code
* Updates to backend bucket and transport.go from MM
* add generated http(s)_health_check resources
* name is required; transport import style
* update docs with new fields/timeouts
* fixes
* Support `distributionPolicy` when creating regional instance group managers.
* Better match the API structure of distributionPolicy.
* Switch to "distribution_policy_zones".
This approach lets us more simply allow a list of zones to use, while
providing a deprecation path for implementing the distribution policy
field more holistically, avoiding backwards-incompatible changes.
* fix typo
* use slice instead of Set for flattenDP
* vendor container/v1beta1
* revendor container/v1beta1
* add beta scaffolding for gke resources
* fix json unmarshal error
* fix issues with trying to convert interface instead of struct
* same fixes but for node pool
* move setid calls back
* Expose first ip address on sql db instance.
Signed-off-by: Desmond Pompa Alarcon Rawls <captaingrover@gmail.com>
* Use the ip_address key on the first map in ip_address list.
Signed-off-by: Genevieve LEsperance <glesperance@pivotal.io>
* Run first_ip_address test check if there is an ip address.
Signed-off-by: Desmond Pompa Alarcon Rawls <captaingrover@gmail.com>
* Add first_ip_address to sql db instance scheme.
Signed-off-by: Genevieve LEsperance <glesperance@pivotal.io>
The GCP backend apparently lowercases the values, no matter what you
enter, so we consider uppercase and lowercase values to be equivalent.
This fixes#862.
