feat(ske): add datasource to query provider options

[h3adex]

Description

This PR adds the ske options API as datasource to query kubernetes and machine versions. Currently the API does not support any filtering option, but this can be done in the meanwhile using terraform locals. Example code is in the generated docs.

data "stackit_ske_provider_options" "this" {}

locals {
  k8s_versions = [
    for v in data.stackit_ske_provider_options.this.kubernetes_versions :
    v.version if v.state == "supported"
  ]
  first_k8s_version = length(local.k8s_versions) > 0 ? local.k8s_versions[0] : ""
  last_k8s_version = length(local.k8s_versions) > 0 ? local.k8s_versions[length(local.k8s_versions) - 1] : ""


  flatcar_supported_versions = flatten([
    for mi in data.stackit_ske_provider_options.this.machine_images : [
      for v in mi.versions :
      v.version if mi.name == "flatcar" && v.state == "supported"
    ]
  ])

  ubuntu_supported_versions = flatten([
    for mi in data.stackit_ske_provider_options.this.machine_images : [
      for v in mi.versions :
      v.version if mi.name == "ubuntu" && v.state == "supported"
    ]
  ])
}

output "first_k8s_version" {
  value = local.first_k8s_version
}

output "last_k8s_version" {
  value = local.last_k8s_version
}

output "k8s_versions" {
  value = local.k8s_versions
}

output "ubuntu_supported_version" {
  value = local.ubuntu_supported_versions[0]
}

output "flatcar_supported_version" {
  value = local.flatcar_supported_versions[0]
}

Checklist

• [x] Issue was linked above
• [x] Code format was applied: make fmt
• [x] Examples were added / adjusted (see examples/ directory)
• [x] Docs are up-to-date: make generate-docs (will be checked by CI)
• [x] Unit tests got implemented or updated
• [x] Acceptance tests got implemented or updated (see e.g. here)
• [x] Unit tests are passing: make test (will be checked by CI)
• [x] No linter issues: make lint (will be checked by CI)

[hown3d]

Even if the API does not allow for filtering at the moment, we should still support filtering in the terraform go code. Using locals may be possible, but is not a nice API and not something I want to recommend.

[hown3d]

Closes https://github.com/stackitcloud/terraform-provider-stackit/issues/953

[github-actions[bot]]

This PR was marked as stale after 7 days of inactivity and will be closed after another 7 days of further inactivity. If this PR should be kept open, just add a comment, remove the stale label or push new commits to it.

[h3adex]

@rubenhoenle

I've just implemented your suggestion. While some work remains, could you please verify if this approach is heading in the right direction? I've split the functionality into 5 different data sources:

stackit_ske_kubernetes_versions stackit_ske_machine_image_versions

Will also get the versionState flag once it is merged into the go-sdk: https://docs.api.stackit.cloud/documentation/ske/version/v2#tag/ProviderOptions https://github.com/stackitcloud/stackit-sdk-go/pull/3786

I haven't yet identified a customer use case for the stackit_ske_volume_type data source. I'll reach out to our SKE team to request that they provide IOPS data through the API, allowing customers to filter volume names based on IOPS.

[hown3d]

I'll reach out to our SKE team to request that they provide IOPS data through the API, allowing customers to filter volume names based on IOPS.

The returned volume types are the ones from IaaS. You can query the IOPS from their API for the volume type. Don't overload this datasource.

[h3adex]

I'll reach out to our SKE team to request that they provide IOPS data through the API, allowing customers to filter volume names based on IOPS.

The returned volume types are the ones from IaaS. You can query the IOPS from their API for the volume type. Don't overload this datasource.

I've split the single data source into multiple smaller ones, as suggested by Ruben. The only particularly relevant ones in this case are the stackit_ske_kubernetes_versions and stackit_ske_machine_image_versions data-sources.

Here’s a quick summary of the others:

• stackit_ske_availability_zones – Might be useful, but we also have an IaaS API for this, which could be integrated instead:
  https://docs.api.stackit.cloud/documentation/iaas/version/v2#tag/Regions-and-Availability-Zones/operation/v2ListAvailabilityZones

• stackit_ske_kubernetes_versions – We definitely need this.

• stackit_ske_machine_image_versions – We definitely need this as well.

• stackit_ske_volume_types – There is an existing API:
  https://docs.api.stackit.cloud/documentation/iaas/version/v2#tag/Flavors/operation/v2ListVolumePerformanceClasses
  However, it hasn’t been integrated into Terraform yet.

• stackit_ske_machine_types – We already have a data source for this:
  https://registry.terraform.io/providers/stackitcloud/stackit/latest/docs/data-sources/machine_type

If everyone agrees, I’d suggest editing this PR to only merge the following essential data sources into upstream (along with support for the version_state flag):

• stackit_ske_kubernetes_versions
• stackit_ske_machine_image_versions

[github-actions[bot]]

This PR was marked as stale after 7 days of inactivity and will be closed after another 7 days of further inactivity. If this PR should be kept open, just add a comment, remove the stale label or push new commits to it.

[h3adex]

Will be fixed in january

[github-actions[bot]]

This PR was marked as stale after 7 days of inactivity and will be closed after another 7 days of further inactivity. If this PR should be kept open, just add a comment, remove the stale label or push new commits to it.