Add Default Kubernetes Version for Dry-Run

[Alero-Awani]

Description

This update improves the handling of Helm charts that do not specify a kubeVersion in their chart.yaml, an example is this redis chart in the image above. The default fallback was Kubernetes version v1.20.0 which affected the rendering of templates and caused this issue.

This change ensures that when kubeVersion is not specified, the Helm dry-run process will fall back to the current version of the Kubernetes cluster in the playground environment.

Notes for Reviewers

Ideally, the version constraint retrieved from chart.Metadata.KubeVersion should not be used to determine the Kubernetes version for the dry run. Instead, the dry-run should utilize the current Kubernetes cluster version to ensure that Helm chart constraints are validated against our cluster's version rather than a potentially outdated version specified in the chart's metadata.

During a Helm dry-run, there is no actual interaction with the live Kubernetes cluster, meaning the process doesn't query the cluster to retrieve the current version. So in this case hardcoding will be better.

Signed commits

• Yes, I signed my commits.

[welcome]

Yay, your first pull request! 👍 A contributor will be by to give feedback soon. In the meantime, please review the Layer5 Community Welcome Guide and sure to join the community Slack.
Be sure to double-check that you have signed your commits. Here are instructions for making signing an implicit activity while peforming a commit.

[MUzairS15]

@Alero-Awani Similar issue was encountered for one of the other helm chart. To tackle the issue initially I also followed the same approach as you are doing in this PR (falling back to the playground cluster) but it isn’t resilient enough. Hence I shifted to using the helm’s default version. It seems Helm default version also cannot handle the case.

I think in these scenarios, it will be better to use most recent version of the k8s model available in the registry.

[Alero-Awani]

Oh yes , I saw the issue. This one here.

You are right, in that case the metadata version is good. Specifically in a scenario where the kubeVersion specified in the chart.yaml is less than(<) the current cluster version.

This particular PR just catches if the kubeVersion was not specified at all in the chart.yaml

I have tested it with a few charts too.

[MUzairS15]

@Alero-Awani Let's accept this, I will update to use version from registry in a follow-up PR.

[welcome]

Thanks for your contribution to Meshery! 🎉