Docker: replace the use of containerd_version with docker_containerd_version

[cristicalin]

Avoid causing conflicts when bumping containerd_version when docker does not keep up with the latest containerd releases.

What type of PR is this?

/kind bug

What this PR does / why we need it:
With the change of using containerd from upstream instead of the docker repos, we are now able to move faster than docker for the containerd runtime but we want to avoid breaking the docker deployment experience when bumping our default containerd version. As such I split the containerd_version into a dedicated deployment variable called docker_containerd_version which is used when the containerd_manager == docker.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

[Docker] When using `containerd_manager==docker` (default config) you will now need to use `docker_containerd_version` to change the containerd version instead of the established `containerd_version`

[floryut]

@cristicalin I'm not sure I get the idea here. If you are using docker then you can specify containerd_version to do exactly that; why introduce a new variable ?
Maybe clarify the doc to explain that containerd_version can be use when container manager is Docker, to change the containerd version deployed.

Edit: Ok this is linked to #8129 ? You want to be able to set containerd_version to 1.4.11 while keeping docker_containerd_version to 1.4.9 ?

[cristicalin]

The problem comes from using containerd_version in the docker role which makes changing the default version tricky since the docker versions of containerd don't keep up with the versions from upstream containerd. In this case when we bump containerd_version to 1.4.11 or 1.5.7 for example, like I tried to do in #8129, the docker role breaks when running its molecule tests.

In addition to this, setting the containerd_version to something that only docker supports (like 1.4.5 version) and we don't have the hashes for, breaks the download role even if you only want to deploy using the docker engine. for this corner case I added the latest entry to our containerd_archive_checksums, which is something of an ugly hack.

Splitting the two types of containerd deployments makes more sense to me but I'm open to other suggestions to ensure we don't break either deployment type and are still able to keep up to date with the upstreams or each docker and containerd.

[cristicalin]

@floryut

Edit: Ok this is linked to #8129 ? You want to be able to set containerd_version to 1.4.11 while keeping docker_containerd_version to 1.4.9 ?

That is the intention yes, explained in long form in the previous comment.

[cristicalin]

@floryut @oomichi can we get this merged ?

[floryut]

@floryut @oomichi can we get this merged ?

Fine by me, sorry forgot this one 🙇

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cristicalin, floryut

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 [floryut]

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

[oomichi]

/lgtm