Template functions for recommended kubernetes versions

[olemarkus]

This PR implements two template functions for setting recommended k8s version based on info from the given channel.

[rifelpet]

These function names are pretty long.

This is essentially the recommended patch version for a given kubernetes version and the function below is the recommended minor+patch version for a given kops version.

How about:

ChannelRecommendedKubernetesPatchVersion
ChannelRecommendedKubernetesMinorVersion

or even just

ChannelKubernetesPatchVersion
ChannelKubernetesMinorVersion

?

[olemarkus]

Not the easiest functions to name :)

I mainly based the function names after the primary underlying function. I don't mind long function names; it boils down to what most intuitive for users.

[olemarkus]

I realise that channel is actually something we pass in as a value.
I could pass channel name as a param to these template functions, but I think the overall code would be more awkward.
A better alternative may be to make the value of the channel CLI arg available as a function too.

Any thoughts?

[rifelpet]

Yea, I don't have a strong opinion about how these should work or their name though I do see the value in having them. Perhaps your original names are sufficient.

I do think its worthy of some documentation so that users don't have to dig into the source code to find the function names.

I'm also wondering if not specifying --channel should use the default channel or not load any channel and have those functions fail somehow. I suppose it only really impacts airgapped environments since toolbox template used to not make any network requests and now it does by default. If we go with the default channel then we should consider a release note mentioning the change in behavior.

[olemarkus]

My documentation got lost somewhere ... I had actually written that.

Those who run kops in airgapped envs could point to their local channel files. I would guess they have one in order to update their clusters as well.

I'll dig up those docs again, add a bit of release notes, but otherwise keep this PR as is. There is sufficient time to change anything later on. And I have some more similar functions I want to add such as recommended image.

Recommended image would also require cloud to be passed though. Which means either passing that as a variable or as another CLI arg similar to the channel discussion above.

[rifelpet]

Yes, I think all of that sounds good 👍🏻

Airgapped users can use their local channel file but they'll need to know to add the --channel flag pointing to their local file when upgrading to kops 1.20, which is what I think the release notes could help with.

[olemarkus]

Actually saving files to disk seems to make a difference ... docs pushed.

[k8s-ci-robot]

@olemarkus: The following tests failed, say /retest to rerun all failed tests:

Test name	Commit	Details	Rerun command
pull-kops-e2e-k8s-containerd	673fa24	link	/test pull-kops-e2e-k8s-containerd
pull-kops-verify-hashes	673fa24	link	/test pull-kops-verify-hashes

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[rifelpet]

This LGTM. Once the conflict is resolved we can get it merged

[rifelpet]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: olemarkus, rifelpet

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [rifelpet]

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