OCM-22845 | feat: return available_channels in the rhcs_version data source

[BraeTroutman]

PR Summary

Adds a new available_channels field to the rhcs_version data source, that will allow users of said data source to view the channels on which a particular version is available. This is a direct propogation from the available_channels field from the versions REST API object on the CS side

Detailed Description of the Issue

Users of the rhcs TF provider have the ability to list and filter OCP versions available from the OCM API. This resource, rhcs_versions, currently only returns two computed values: name and id, which can be used in a cluster or machinepool creation.

Now that we have the channel property coming to clusters, users should also be able to see the channels available to a version, so that they can manage the channels they assign to a cluster (if any) in the same declarative way that they manage versions.

Related Issues and PRs

• Jira: OCM-22845
• Fixes: #
• Related PR(s): OCM-22481 | chore: bump ocm-sdk-go to v0.1.497 #1089
• Related design/docs: https://github.com/chenz4027/rosa-enhancements/blob/7adf80d97ef37a5dedf8a234dd72eecc965ff121/enhancements/managed_openshift_supports_y%2B1.md#4-terraform-changes

Type of Change

• feat - adds a new user-facing capability.
• fix - resolves an incorrect behavior or bug.
• docs - updates documentation only.
• style - formatting or naming changes with no logic impact.
• refactor - code restructuring with no behavior change.
• test - adds or updates tests only.
• chore - maintenance work (tooling, housekeeping, non-product code).
• build - changes build system, packaging, or dependencies for build output.
• ci - changes CI pipelines, jobs, or automation workflows.
• perf - improves performance without changing intended behavior.

Previous Behavior

the rhcs_versions data source only computes id and name fields

Behavior After This Change

the available_channels computed field is added to the versions datasource in both item and items types. Behavior of filtering and item vs items population should be unchanged (i.e. they're still populated in the same way. This is tested in the classic subsystem tests)

How to Test (Step-by-Step)

Preconditions

• valid OCM log in (preferably a client id + client secret) but the output of your ocm token is also valid.

Test Steps

1. if testing before merge of this PR, run make install to install the local TF provider
2. create a local terraform directory for testing, e.g. mkdir version-channels-tf
3. create the following main.tf:

# file: main.tf
terraform {
  required_providers {
    rhcs = {
      source  = "terraform.local/local/rhcs" # note this should be terraform-redhat/rhcs if you're using the official provider
      version = ">= 1.7.5"                                 # this also may need to be updated to match the tagged version if building locally
    }
  }
}

provider "rhcs" {
  client_id     = "***"
  client_secret = "***"
  token_url     = "https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token"
  url           = "https://api.integration.openshift.com"
}

data "rhcs_versions" "version_info" {
  search = "id = 'openshift-v4.16.50'"
}

output "channels" {
  value = data.rhcs_versions.version_info.item.available_channels
}

Expected Results

When running terraform apply:

channels = tolist([
  "candidate-4.17",
  "candidate-4.18",
  "eus-4.16",
  "eus-4.18",
  "fast-4.17",
  "fast-4.18",
  "stable-4.17",
  "stable-4.18",
])

Currently all versions should have available_channels, so there should be no situation in which this output would be empty: that possibility is nevertheless accounted for in subsystem tests in which the list of available channels is expected to be empty

Proof of the Fix

• Screenshots:
• Videos:
• Logs/CLI output:
• Other artifacts:

Breaking Changes

• No breaking changes
• Yes, this PR introduces a breaking change (describe impact and migration plan below)

Breaking Change Details / Migration Plan

Developer Verification Checklist

• Commit subject/title follows [JIRA-TICKET] | [TYPE]: <MESSAGE>.
• PR description clearly explains both what changed and why.
• Relevant Jira/GitHub issues and related PRs are linked.
• Tests were added/updated where appropriate.
• I manually tested the change.
• make test passes.
• make fmt passes.
• make build passes.
• Documentation was added/updated where appropriate.
• Any risk, limitation, or follow-up work is documented.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign olucasfreitas for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[BraeTroutman]

/retest-required

[olucasfreitas]

@BraeTroutman Can we add a test case in the subsystem tests, where available_channels is missing or empty in API response to validate edge behavior for this new field?