Boovan Rajendran 8edb19bdd5 Enhance k8s-container-cleanup.sh to operate during upgrade abort
This change is to add optional argument 'force-clean' to
stop all containers during 'system kube-upgrade-abort'.
The default usage of this script with no options only performs
cleanup during systemd 'stopping' phase.

Test-plan:
Pass: During 'system kube-upgrade-abort' process verify the puppet.log
and check '/usr/sbin/k8s-container-cleanup.sh  force-clean' is
executed successfully.
Pass: Manually execute '/usr/sbin/k8s-container-cleanup.sh force-clean'
verify all the containers have exited.
Pass: Manually execute the script by passing the wrong argument
"/usr/sbin/k8s-container-cleanup.sh clean-force" and verify it
gives the appropriate error message -
"usage: /usr/sbin/k8s-container-cleanup.sh { force-clean }"

Story: 2010565
Task: 48094

Change-Id: I8029e89b600cb644bfa4a83f3208e677878f19e7
Signed-off-by: Boovan Rajendran <boovan.rajendran@windriver.com>
2023-05-30 00:08:39 -04:00
..
2023-05-16 17:36:01 -04:00
2023-05-16 17:36:01 -04:00
2023-05-16 17:36:01 -04:00

The containerd.service file and config.toml were pulled in
from the upstream Debian package
containerd_1.6.20~ds1-1+b1_amd64.deb downloaded from
http://ftp.ca.debian.org/debian/pool/main/c/containerd/

The config.toml file is identical to what we were using previously
with the older version of containerd, and is unchanged in the
newer version of the package.  It will get overwritten by
ansible/puppet anyways during system bringup.

The containerd.service file is identical to the version from
the containerd github source tag "v1.6.21" except that the
containerd binary is in /usr/bin/ instead of /usr/local/bin.
The only difference from what we had before is that LimitNOFILE
is now set to "infinity" to align with both Debian and containerd
upstream.

The binaries that get pulled in at build time are from the
containerd upstream binary release
containerd-1.6.21-linux-amd64.tar.gz downloaded from
https://github.com/containerd/containerd/releases/tag/v1.6.21

The rationale for using the upstream binaries rather than the
Debian "bookworm" package is that the Debian package requires
a lot of other dependencies including newer glibc and python3,
which would be too intrusive for our purposes.