[PRODENG-3641] Option 1: add spec.mcr.installCLI to install docker-ee-cli explicitly

[james-nesbitt]

What

Adds spec.mcr.installCLI (bool, default false). When set, the docker CLI package docker-ee-cli is named explicitly in the MCR install.

This is one of two divergent PRs for PRODENG-3641. The alternative is #656 (installRecommends). They are alternatives, not companions — pick one.

Why

Launchpad installs the runtime with a bare yum install -y docker-ee (equivalently apt-get/zypper) and relies on the package manager to bring in the CLI. A customer on CIS-hardened RHEL 8.10 ended up with the runtime installed and no CLI, so every later docker command failed on a host that otherwise looked correctly installed. Installing docker-ee-cli by hand and re-running launchpad completed the cluster.

I checked why. Every docker-ee package on repos.mirantis.com lists docker-ee-cli as a recommended package (rpm Recommends / deb Recommends), never as a hard Requires/Depends:

Platform	Channels checked	CLI relationship
rhel 8, rhel 9	stable-25.0, stable-29.2	Recommends only
sles 15	stable-25.0, stable-29.2	Recommends only
ubuntu jammy, noble	stable-25.0, stable-29.2	Recommends only

Package managers install recommended packages by default, which is why this normally works unattended. Hardening baselines commonly disable exactly that — install_weak_deps=false (dnf/yum), APT::Install-Recommends "false" (apt), solver.onlyRequires (zypper). Naming the package explicitly bypasses that resolution entirely.

How

• MCRConfig.InstallCLI — installCLI in yaml, documented including that Windows ignores it.
• configurer.MCRPackages() returns the package list, so the names live in one place rather than being repeated across three configurers.
• Both packages are passed in a single package-manager invocation, not two calls, so the runtime and CLI cannot resolve to mismatched versions.

Default stays false deliberately: recommended packages are installed by default on an unhardened host, so installing the CLI unconditionally would change what every existing cluster installs in order to work around an environment-specific setting.

Trade-off versus the alternative

• This PR: identical two-package behaviour on every platform, no surprising footprint, keeps rig's InstallPackage. Cost: a hardcoded package list that can drift from repository metadata, and it does not address cri-dockerd-ee, which is also only a recommended package and which launchpad never installs explicitly.
• The installRecommends PR: delegates the list to repository metadata so it cannot drift and covers cri-dockerd-ee too. Cost: on deb hosts it additionally installs git, pigz, procps, xz-utils, ca-certificates, libltdl7, docker-ee-rootless-extras and a kernel package; and it requires running package-manager commands directly on all three families.

Testing

• TestMCRPackages — default is runtime-only; installCLI adds the CLI; runtime stays first and both are returned together for a single transaction.
• TestMCRConfig_InstallCLI — the yaml key round-trips (absent → false, true/false honoured). A wrong struct tag would silently ignore the setting and reintroduce the bug for anyone opting in.
• Both were confirmed to fail with the default flipped, so they discriminate.
• make lint clean (0 issues), go vet, go vet -tags=integration, gofmt, full unit suite green.

Not smoke-tested: the failure mode needs a host with weak dependencies disabled, which no smoke platform currently provides.

Open question

This is a mitigation, not a root-cause fix. The reason resolution skipped the CLI on that specific host is still unconfirmed — the customer's launchpad config, docker-ee.repo and apply.log were requested on the ticket and have not arrived. If their install_weak_deps is set, that confirms it; if not, something else is going on and this flag may not help them.

Links

• JIRA: PRODENG-3641

Written by AI: claude-sonnet-5