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.
* 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
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.
* 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
* 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
* 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
* 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
* 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
* Remove bad test in testAccContainerCluster_withIPAllocationPolicy
One step was expecting the test to fail if the subnetwork defines
secondary ip ranges that the cluster doesn't use. However, it is
perfectly fine to do so and we don't expect an error.
* Revert "Remove bad test in testAccContainerCluster_withIPAllocationPolicy"
This reverts commit af2f369907181a107cfc0ed9fa2ff0e288f02f66.
* Fail if use_ip_aliases is true and no range names is provided
* make fmt
* don't introduce new field for now. Wait until we want to support new feature in allocation policy
- Fetch Zone attribute any place where it *was* being fetched from the schema by
combination schema / provider-level attribute.
- Allow region to be unspecified if zone is specified.
- Switch one example to using provider-level zone as an example.
- Make provider-level zone optional. (Individual resources will fail if they can't find a zone.)
- Add tests for getZone and getRegion.
* add support for ip aliasing in `google_container_cluster`
* [review] cleanup galore, infer feature enablement from `ip_allocation_policy`
* [review] cleanup, round 2
* add nil check back (when reading ip allocation policy from API)
* Relax diff on maintenance_policy.daily_maintenance_window.start_time
If the maintenance window has been set outside of Terraform to a time with a
single-digit hour (such as 1:00), and the terraform definition is set to the
same hour but with a leading zero as per validation (i.e. 01:00), do not
consider the time to be changed (as we currently don't support update on this
property).
Fixes#719
* Generalise rfc3339TimeDiffSuppress and add more test cases