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.
An instance is an abstract container of clusters, it's the cluster that
has the nodes and holds the data, so the number of nodes and location
apply to the cluster.
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.
* Added a link to the console page where you can download a file
* Removed instructions on how to get to that page, since now you can just click on the link
* Added caveat for application default credentials
@sethvargo @theacodes @kimcam let me know if this seems reasonable / you have any suggestions!
If you try and specify them together you will get this error:
google_compute_global_forwarding_rule.your-rule: Error creating Global Forwarding Rule: googleapi: Error 400: Invalid value for field 'resource.ipVersion': 'IPV4'. Both IP Version and IP Address cannot be specified., invalid
* 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.
* Clarify format of GCP machineType property
This should not be in a URL style formatting, which the previous language seemed to be implying
* machineType docs for compute_instance_template
* Remove some accidental spaces
* Update from feedback
Closes GH-1323
* Update container_cluster.html.markdown
Just a more clear explanation of what happens when this field is not provided, since there was already an issue with this topic.
* Update container_cluster.html.markdown
Cleared extra comma.
* Add "server_ca_cert" Attribute reference
Documents the addition of the `server_ca_cert` attribute for use in configuring SSL with GCP SQL Instances - added in PR #1020
* Updated formatting
Updates formatting to match the above fields.
* 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
The docs currently don't use the datasource version of
'google_client_config'. This PR just prefixes 'data.'
to 'google_client_config' in the datasource docs.
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
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.