- config.clientCompute.Routers
- peer fields renamed
- more consistent logging
- better handling of SetId for error handling
- function for router locks
- test configs as functions
- simplify exists logic
- use getProject, getRegion logic on acceptance tests
- CheckDestroy for peers an interfaces
- dynamic router name for tunnel test
- extra fields for BgpPeer
- resource documentation
- config.clientCompute.Routers
- peer fields renamed
- more consistent logging
- better handling of SetId for error handling
- function for router locks
- test configs as functions
- simplify exists logic
- use getProject, getRegion logic on acceptance tests
- CheckDestroy for peers an interfaces
- dynamic router name for tunnel test
- extra fields for BgpPeer
- resource documentation
The current google_compute_url_map resource already supports backend
buckets out of the box: Just pass the self_link of the backend buckets
as you would pass the self_link of a backend service.
This adds some example code as well.
Unset id in case the backend service cannot be created. This basically
updates these lines of code to match the more modern style which is
being used e.g. for the google_compute_instance resource.
When trying to run the example code with the most recent terraform
master you get the following errors:
```
2 error(s) occurred:
* google_compute_backend_service.home: "region": [REMOVED] region has been removed as it was never used
* google_compute_backend_service.login: "region": [REMOVED] region has been removed as it was never used
```
Hence remove it from the documentation.
We've supported GOOGLE_APPLICATION_CREDENTIALS as an environment
variable (it comes free with our OAuth2 client) but it has never been
documented. Documenting it now to resolve#12626.
Update our project metadata tests to stand up their own projects, so
they don't trample all over each other anymore.
The fixes for this were more invasive than I had hoped they would be,
but the tests all pass now (when run sequentially) and there's no reason
for them not to pass when run in parallel.
We have tests failing because we hard-coded the network name in our
network data source test. By randomizing it, we don't fix the dangling
resource problem, but do make the tests pass again.
Update our docs for `google_compute_forwarding_rule` to clarify that the
`ip_address` field expects a literal IP address and will not accept the
`self_link` property of a `google_compute_address` resource.
Prompted by #13375
* first version of this datasource
* add network and subnetwork datasource and documentation
* modify sidebar reference in documentation
* fix elements after review on network and subnetwork datasources
* fix fmt on Google provider.go
* modify code with the review
* modify documentation layout order
* fix alphabetic order in provider.go
* fix rebase issue and documentation datasource => data
* first version of this datasource
* add network and subnetwork datasource and documentation
* modify sidebar reference in documentation
* fix elements after review on network and subnetwork datasources
* fix fmt on Google provider.go
* modify code with the review
* modify documentation layout order
* fix alphabetic order in provider.go
* fix rebase issue and documentation datasource => data
