-
Notifications
You must be signed in to change notification settings - Fork 9.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move GCP projece attribute onto resources, inherit from provider #6112
Conversation
The current implementation returns error as the first parameter, but it is usually the last parameter.
This is the first step in removing the config dependency on "project". This change is backwards-compatible because the value for this new attribute defaults to the value from the provider.
This commit also normalizes the format we display attributes.
One important thing to note here is the plan vs. apply validation. Because the provider is not configured during provider "google" {
credentials = "${file("creds.json")}"
}
resource "google_compute_network" "default" {
name = "test"
ipv4_range = "10.0.0.0/16"
} This is because, due to the way providers are loaded, we don't have the provider data until we start running the function. As such, the I think this is "ok" until we can refactor Terraform's core to load provider configs in validateWalk, and I saw this pattern already exists in a few other places in Terraform. In reality, the probability for that type of error is quite minimal, and the gained-tradeoff is that we can now manage multiple projects in a single Terraform config 😄 |
// getRegion reads the "region" field from the given resource data and falls | ||
// back to the provider's value if not given. If the provider's value is not | ||
// given, an error is returned. | ||
func getRegion(d *schema.ResourceData, config *Config) (string, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for moving these in in here, resource_compute_address.go
definitely wasn't the place for getRegion
.
Hey just to make sure I didn't miss anything: You'll be adding the Otherwise, LGTM! Thanks for updating the docs too. |
Hey @lwander Yup! This PR was already rather large, so I didn't want to add any new resources yet. I'm going to do that in another PR once this lands in core 😄 |
@lwander whoops, missed the second part of your Q: All the |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
This commit uses the existing pattern in the provider for "region", but extends it to "project" as well. Currently the provider is heavily tied to a project. Some of the upcoming APIs (that we would like to leverage) do not require a project id. This PR decouples the provider configuration from the project configuration, but does so in a backwards-compatible way.
Highlight changes:
/cc @lwander @jen20