Feature request: K8s version latest label

[RuriRyan]

Current Provider Version

latest

Use-cases

When managing multiple k8s clusters via terraform it gets quite tedious when a new k8s version (minor or patch-level) is released.

Proposal

My proposal would be a set of labels which translate to corresponding versions. Like a latest label which points to the current default version (https://api.ionos.com/cloudapi/v5/k8s/versions/default). Also some convenience labels which ignore the patch version would be nice, like 1.18 which then points to the latest 1.18 version as defined in the versions list (https://api.ionos.com/cloudapi/v5/k8s/versions).

This also makes checking for upgrades easier as you can just run terraform plan, which then can show if a cluster/nodepool needs to be upgraded.

Example

https://api.ionos.com/cloudapi/v5/k8s/versions:

[
  "1.17.13",
  "1.17.12",
  "1.18.5",
  "1.18.12",
  "1.18.14",
  "1.18.9",
  "1.19.2",
  "1.19.4"
]

https://api.ionos.com/cloudapi/v5/k8s/versions/default:

"1.18.12"

resource "profitbricks_k8s_cluster" "example" {
  name        = "example"
  k8s_version = "latest" # translates to 1.18.12
  maintenance_window {
    day_of_the_week = "Monday"
    time            = "09:30:00Z"
  }
}

resource "profitbricks_k8s_cluster" "example" {
  name        = "example"
  k8s_version = "1.18" # translates to 1.18.14
  maintenance_window {
    day_of_the_week = "Monday"
    time            = "09:30:00Z"
  }
}

[LiviusP]

Hi @RuriRyan ,

1. I would rather call the label "default" as it's poiting to the default version rather than the latest one.
2. I will forward the second requirement to the API team, as IMHO it would make more sense to have it available straight in the API, such feature, including the "latest" label which would really choose the latest version, it this case 1.19.4.

Would this approach be ok with you?

Thanks! Livius

[RuriRyan]

1. I don't have a strong opinion on what the labels are called. I guess "default" is also fine.
2. The problem here is when the API handles the labels you might get updated to a new version without any notice, since the API can't really ask for a confirmation. But when this is handled by terraform it can show you that it will also apply an update on the next run. This is especially helpfull if you need to migrate some deployments or so.

[LiviusP]

Ok. Sounds good to me. We'll prioritize this one and try to see what we can achieve via terraform in this regards.

[jbuchhammer]

Having some labels/aliases for k8s versions would be a real benefit. I agree with Livius in both points, especially that it should better be implemented in the Cloud API. This way every SDK/Tool would have a benefit, not only terraform. IMHO, regardless where these aliases are introduced, the main challenge is the mapping in terraform for the state file: Every plan/apply has to resolve the alias first and compare to the current state, which has to be a specific version and then leads to a change or no change.