-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
terraform plan errors when the provider's default project is unknown during plan #16133
Comments
@queeno in below config, do you intend to set resource "google_service_account" "test" {
provider = google.test_project. <------ project or provider?
display_name = "test-service-account"
account_id = "test-service-account"
} |
The DefaultProviderProject, DefaultProviderRegion and DefaultProviderZone funcs set respectively the project, region and zone in a diff if one is provided, unless they fetch the defaults from config. However, at times, these value may not be available during a plan, as they are dynamically computed at apply time. We should avoid throwing an error if this is the case, but rather set an empty value in the diff. Resolves hashicorp#16133
@edwardmedia I intend to set the provider |
We may want to guard this on a setting- with the current |
It appears that not all resources enforce this 'strict' mode. I've noticed that, out of 706 resources, only 312 seem to include the provider check. A list of non-supported resources is available here I only realised because this check was introduced in 5.0.0 on the I'd argue that, would we want to enforce a 'strict' mode on plan, we should make sure that the check is run on all resources. Furthermore, I'm also wondering what the benefit of a 'strict' mode would be.
|
To explain part of this as the one who implemented the change: the resources without the defaultprovider/region/zone displays were those that do not support using system default values on the project field or for which project was not a part of the schema. There was some false positives in making the list of resources to not apply including it to ( |
Yes to both! The change was made to help make plans more explicit about resources were going, and to improve the validation of users' configurations at plan time.
I believe we can reliably check this at the resource level, but not at the provider level where both unknown and unset are considered the same value. That's where guarding behind a flag could help, unless we can gather more information. For the majority of configurations where provider default projects are known we can move project validation up to plan time, and users who are using providers whose attributes are determined mid-apply could ignore that validation. We didn't capture that flow correctly- I knew it was possible, having worked with the Kubernetes provider and GKE resources within a single config, but didn't think it would be relevant for this change. We'll do some investigation and see if we can find a way to detect unknown values on the provider, and investigate a flag or alternative if we can't.
Organization-level resources ( There are similar complications throughout other resources that mean this check can't be universal. That's not a guarantee that we applied it to every possible resource, but I don't think we'd reliably be able to promise literally every resource behaved as expected (particularly because backfilling resources we missed will need to happen in major versions). |
I am getting all kinds of pain when I do something similar. but I do this:
I also create the project in my root module an I want to create this service account within the context of that project that is created within the current module (hence the reference to the project resource. I get this very strange error:
Seems like the project attribute of the the 'google_service_account' resource type is not building the correct path to the API it's calling. Not sure why. |
@rileykarson @NickElliot I'm seeing the same issues after upgrading to v5, using basically something like the below. What's the proper way to provision projects like this, as this doesn't seem to be "the way"? resource "random_integer" "main" {
min = 1
max = 99999
}
locals {
project_slug = "test"
project_id = "${local.project_slug}-${random_integer.main.id}"
}
resource "google_project" "main" {
project_id = local.project_id
}
resource "google_project_service" "serviceusage-api" {
service = "serviceusage.googleapis.com"
project = local.project_id
disable_on_destroy = false
depends_on = [
google_project.main
]
}
provider "google" {
project = local.project_id
} https://cloud.google.com/docs/terraform/best-practices-for-terraform#randomize |
Community Note
modular-magician
user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned tohashibot
, a community member has claimed the issue already.Terraform Version
Affected Resource(s)
Terraform Configuration Files
Debug Output
TF plan output
Expected Behavior
A plan should have been created.
Actual Behavior
The following error is observed:
Steps to Reproduce
terraform plan
The text was updated successfully, but these errors were encountered: