Terraform-provider-digitalocean: Add digitalocean_kubernetes_cluster.auto_upgrade

[MarianoRD]

Affected Resource(s)

• digitalocean_kubernetes_cluster

Terraform Configuration Files

resource "digitalocean_kubernetes_cluster" "foo" {
  name    = "foo"
  region  = "nyc1"
  version = "1.12.1-do.2"

  node_pool {
    name       = "worker-pool"
    size       = "s-2vcpu-2gb"
    node_count = 3
  }
}

Expected Behavior

Have the option to enable auto upgrade, and even as the updates are patches of the same version of Kubernetes have it default to true.

Actual Behavior

The cluster gets created without auto upgrade enabled.

References

• API endpoint allows it
• Godo has the option

[lfarnell]

I'm interested in adding this feature but wanted to clarify some of my assumptions and hopefully get some feedback on it. Currently, the resource requires a version of the Kubernetes cluster one wishes to provision. Once the new auto_upgrade attribute is set to true the state and config will be out of sync when the cluster updates itself. My proposal is to add min_versionand deprecate the version attribute. Both will work in tandem until version is removed in a major version. If auto_upgrade is false(default) then the Kubernetes version will be the value of min_version. If auto_upgrade is true then min_version must >= the min_version.

[MarianoRD]

I haven't thought about that. Enabling auto_upgrade will indeed make the states and the infrastructure diverge. I think changing the logic of the version might be a good idea. Or making auto_upgrade + min_version mutually exclusive with version. That way, you can still have a static version that gets overwritten to a min_version if auto_upgrade = true, that might be easier on code than changing the already existing logic.

[andrewsomething]

Hey @lfarnell! Sorry for the delayed review on the PR. I've been mulling this one over for a bit. The auto_upgrade piece itself looks good, but as you pointed out here this is going to cause an issue with how version is implemented. Currently, if the version were to change Terraform would want to force a new resource.

Thinking aloud bit.. If we wanted to avoid deprecating version, we could potentially use a CustomizeDiff function here. Something like:

• Remove the ForceNew attribute from version
• Create a CustomizeDiff function using customdiff.ForceNewIf that:
  
  
  
  • If auto_upgrade is false & the new and old version are not equal, returns true
  
  
  • Else (e.g. auto_updated is true or the versions are equal), returns false
  
  

https://www.terraform.io/docs/extend/resources.html#customizing-differences
https://godoc.org/github.com/hashicorp/terraform/helper/customdiff#ForceNewIf

Auto upgrades only work for patch versions, so there could be another case in there. This would get more complicated when adding support for triggering a patch update manually... :thinking:

[botzill]

Hi.

Does autoupgrade works at the moment?

[pjanuario]

I am also in doubt, what approach do we need to take to upgrade a cluster that was created with terraform. What would happen to the terraform state if I upgrade the cluster using the GUI/API/DOCTL? Also what happens if we enable auto upgrade in the gui. :/

Any advise on how to proceed with this?

[botzill]

Also interested about this issue. Thx.

[boredland]

hi! What is the current way to enable auto_upgrade or even set a maintenance_policy?

[cguertin14]

Any progress on this issue? Eagerly waiting for it to exist.

[lfarnell]

Just letting everyone know that this hasn't been solved at this point. Something I've just tested is you can apply a lifecycle block on the Kubernetes resource and upgrade the cluster version without showing a diff in the Terraform state.

lifecycle {
    ignore_changes = [
      version,
    ]
  }

This is a 100% "hack" to allow individuals to upgrade the cluster version without the Terraform state showing a diff on each plan/apply. I would use this sparingly. If I can find some time in the next few weeks, I will try and send another PR for the addition of auto_upgrade and also add maintenance_policy in as well.

[lfarnell]

Ok, I think I may have figured this whole debacle out but I would like it if someone can verify my findings.

So normally we would declare a definition like

resource "digitalocean_kubernetes_cluster" "foo" {
  name    = "foo"
  region  = "nyc1"
  version = "1.12.1-do.2"

  node_pool {
    name       = "worker-pool"
    size       = "s-2vcpu-2gb"
    node_count = 3
  }
}

Now If I use code patch I have locally for enabling auto upgrades and our new maintenance policy(below is the prototype definition), we would have something like

resource "digitalocean_kubernetes_cluster" "foo" {
  name    = "foo"
  region  = "nyc1"
  version = "1.12.1-do.2"
  auto_upgrade = true

  node_pool {
    name       = "worker-pool"
    size       = "s-2vcpu-2gb"
    node_count = 3
  }

  #This is a prototype
  maintenance_policy {
    start_time = "..."
    day = "Sunday"
  }
}

The problem we would now face is that when we enter the maintenance mode and the cluster is potentially upgraded to the newest patch version, our terraform state would diverge. But we if use a data source like such

data "digitalocean_kubernetes_versions" "example" {
  version_prefix = "1.18."
}

we no longer have this problem. Even we doing a major version upgrade to 1.19 once it's available, changing the version to 1.19 in the data source will trigger a cluster upgrade automatically once applied.

[andrewsomething]

Fixed via https://github.com/digitalocean/terraform-provider-digitalocean/commit/a975f658324e8422d5ded62f9d214e99f28b9da8 thanks to @lfarnell!