Adapt checksums and versions to new hashes updater

[VannTen]

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
This (WIP) adapt Kubespray checksums and version to work with the new hashes updater.
I'm pushing this as draft so reviewers of the hashes updaters can test it.

This is pretty invasive, as you can see, mostly because of removing the v-prefix in version (this originates from the design of the updater script, but I've been going with it for consistency).

Which issue(s) this PR fixes:

Special notes for your reviewer:
I'm putting this as ci/extended to avoid breaking stuff

This might be hard to backport, which might preclude automatic PR for hash updates on the (current) releases branches.

Does this PR introduce a user-facing change?:

action required
You should remove the leading 'v' of all explicit version of components deployed by kubespray (most notably `kube_version`)

[VannTen]

/ok-to-test

[VannTen]

/label ci/extended

[k8s-ci-robot]

@VannTen: The label(s) /label ci/extended cannot be applied. These labels are supported: api-review, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash, team/katacoda, refactor, ci-short, ci-extended, ci-full. Is this label configured under labels -> additional_labels or labels -> restricted_labels in plugin.yaml?

In response to this:

/label ci/extended

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-sigs/prow repository.

[VannTen]

/label tide/merge-method-merge

[VannTen]

/label ci-extended

[VannTen]

/retest

[mzaian]

Thanks @VannTen

[yankay]

It's a break change :-)
This is a breaking change. We should highlight it in the release notes.

[VannTen]

I did (with the `action required`). Or maybe you meant something else ?

[VannTen]

Hum, what do you think regarding the README versions ? Should we keep a leading v here or use the same consistency and get rid of it ?

Now that I'm writing it it seems the 2nd option seems to make more sense (I don't care much though, can change if needed)

[yankay]

Hum, what do you think regarding the README versions ? Should we keep a leading v here or use the same consistency and get rid of it ?

Now that I'm writing it it seems the 2nd option seems to make more sense (I don't care much though, can change if needed)

Hello @VannTen ,

This change may cause errors for users who are currently using Kubespray, especially those who use the kube_version variable.

It would be more user-friendly for existing users if we could provide compatibility with the previous v prefix pattern and provide some documentation to help users migrate to the new way.

[VannTen]

I considered doing that.
However, unless we maintain infinite backwards compat, users will have to change their inventories as some point, so why not now ? To that effect, I include e60f68f, which explicitly state the version format change (would you prefer a more imperative tone ?). The change is super straightforward, so I don't see what a deprecation period would buy us in that case.

[yankay]

I considered doing that. However, unless we maintain infinite backwards compat, users will have to change their inventories as some point, so why not now ? To that effect, I include e60f68f, which explicitly state the version format change (would you prefer a more imperative tone ?). The change is super straightforward, so I don't see what a deprecation period would buy us in that case.

Because many existing clusters require maintenance, the compatibility may need to be maintained. It may be solved in another PR later.
Hope more reviewers can help us to review it and give some suggestions on it.

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mzaian, VannTen, yankay

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 [VannTen,mzaian,yankay]

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

[VannTen]

Because many existing clusters require maintenance, the compatibility may need to be maintained.

To put thing in perspective, that really does not need much, just removing 'v' from explicit version defined in your inventory. That looks like a 'less than 5 minutes' change to me, which is why I've done it this way. It's possible to maintain compat with version stating with 'v', but I don't think it's worth the extra variable massaging in kubespray.