Cannot update Kubernetes clusters with version = latest

[AaronFriel]

Bug Report

Creating a Kubernetes Cluster with version = latest fails on subsequent updates.

This was discovered by a Pulumi user here:

• https://github.com/pulumi/pulumi-digitalocean/issues/437

Describe the bug

Setting the version slug to "latest" works on creation, but applying the configuration again results in an API error:

Unable to upgrade cluster version: POST https://api.digitalocean.com/v2/kubernetes/clusters/f6fffdba-b39b-4c0e-99f6-44b5dcd0969d/upgrade: 422 (request "329518b1-a2a4-450d-a2f8-7121bd814b9f") validation error: invalid version slug

If "latest" is supported as an input value, it should be supported on subsequent updates, as Terraform providers should generally be idempotent. A resource configuration that can only apply once results in user confusion.

Affected Resource(s)

• digitalocean_kubernetes_cluster

[andrewsomething]

Hi @AaronFriel,

latest is supported by the DigitalOcean API as a convenience when creating a Kubernetes cluster. It is only supported in the Terraform provider in so far as the version attribute is a string type. So if you set it to that, we'll send it to the API. We recommend specifying a specific version. The current valid versions can be found with doctl kubernetes options versions

If you want to automatically find and use the latest version, we do provide a data source, e.g:

data "digitalocean_kubernetes_versions" "example" {}

resource "digitalocean_kubernetes_cluster" "example-cluster" {
  name    = "example-cluster"
  region  = "nyc3"
  version = data.digitalocean_kubernetes_versions.example.latest_version

  node_pool {
    name       = "default"
    size       = "s-1vcpu-2gb"
    node_count = 3
  }
}

https://registry.terraform.io/providers/digitalocean/digitalocean/latest/docs/data-sources/kubernetes_versions

Though in most cases, you should still prefer using a static version for production workloads as this may lead to unplanned upgrades.

[AaronFriel]

That makes sense, though it seems like the provider should forbid "latest", as refreshing the resource state will result in a different value being returned and subsequent plans & applies will try to apply "latest".

Alternatively,

• When "latest" is sent, "latest" could be returned from the Create/Update implementations
• A separate field could be used to indicate the latest version is desired, such as "useLatest: boolean", with "version" optional. That would allow the API to return the output version.