Skip to content
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

google_container_cluster: enable_autopilot conflicts with remove_default_node_pool when set explicitly to false #20991

Open
guineveresaenger opened this issue Jan 22, 2025 · 3 comments

Comments

@guineveresaenger
Copy link

guineveresaenger commented Jan 22, 2025

Community Note

When setting enable_autopilot explicitly to false which is its default value, terrafrom plan fails with a "Conflicting configuration arguments" message.

The following Terraform configuration:

provider "google" {
  project = myproj
  region  = myregion
}

resource "google_container_cluster" "gke_cluster" {
  name                     = "gke-cluster"
  location                 = mylocation
  remove_default_node_pool = true
  enable_autopilot         = false
}

results in the conflict error.

╷
│ Error: Conflicting configuration arguments
│ 
│   with google_container_cluster.gke_cluster,
│   on main.tf line 9, in resource "google_container_cluster" "gke_cluster":
│    9:   remove_default_node_pool = true
│ 
│ "remove_default_node_pool": conflicts with enable_autopilot
╵

However, commenting out the enable_autopilot line, which should effectively be the same, succeeds.

Terraform Version & Provider Version(s)

Terraform v1.10.2
on darwin_arm64
+ provider registry.terraform.io/hashicorp/google v6.17.0

Your version of Terraform is out of date! The latest version
is 1.10.4. You can update by downloading from https://www.terraform.io/downloads.html

Affected Resource(s)

google_container_cluster

Terraform Configuration

provider "google" {
  project = myproj
  region  = myregion
}

resource "google_container_cluster" "gke_cluster" {
  name                     = "gke-cluster"
  location                 = mylocation
  remove_default_node_pool = true
  enable_autopilot         = false
}

Debug Output

https://gist.github.com/guineveresaenger/b9fd8fed6f816328455e0cb14954228f

Expected Behavior

I expected the plan to succeed - setting enable_autopilot to false should be no different than using the default.

Actual Behavior

Conflict message

Steps to reproduce

Run the above configuration with terraform plan.

Important Factoids

No response

References

Possibly similar? #17045

b/391643648

@ggtisc
Copy link
Collaborator

ggtisc commented Jan 22, 2025

Confirmed issue!

This could be contradictory as user explains since after creating the resource the value of enable_autopilot in the tfstate file is false, but if it is tried to create the resource with the shared configuration it results in the posted error.

@ggtisc ggtisc removed their assignment Jan 22, 2025
@ggtisc ggtisc removed the forward/review In review; remove label to forward label Jan 22, 2025
@KatrinaHoffert
Copy link

Hmm, isn't this standard behavior for the Terraform ConflictsWith schema setting?

// ConflictsWith is a set of schema keys that conflict with this schema.
// This will only check that they're set in the _config_. This will not
// raise an error for a malfunctioning resource that sets a conflicting
// key.

ConflictsWith only accepts names of fields, not values, so it just knows that enable_autopilot is incompatible with remove_default_node_pool (and several other fields). It doesn't know if true or false is incompatible (while the behavior of being unset is identical to an explicit false, it is possible to treat it differently).

I don't think we'd want to reinvent any wheels by doing some kinda custom alternative to ConflictsWith. While perhaps there is ground for a FR for Terraform to make ConflictsWith more powerful (say, a predicate), I'm not sure of the use case for setting an explicit false when the field being omitted is cleaner, anyway.

@NickElliot, can/should this be closed as won't fix, due to being standard behavior of ConflictsWith (and thus outside of the control of a provider)?

@NickElliot
Copy link
Collaborator

NickElliot commented Jan 22, 2025

Correct, this would be the standard behavior of ConflictsWith as it's not about the value being true, but existing in the declared state at all. A situation where API error validation may have proved appropriate (as this state seemingly should work), but this is a common usage of the ConflictsWith to begin with.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants