[PRODENG-3641] Option 2: add spec.mcr.installRecommends, run package managers directly

[james-nesbitt]

What

Adds spec.mcr.installRecommends (bool, default false). When set, the package manager is told to install the runtime's recommended packages regardless of the host's configured default. Also shifts the MCR install to issuing package-manager commands directly on all three Linux families, which is what makes passing those arguments possible.

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

Why

A customer on CIS-hardened RHEL 8.10 ended up with the runtime installed and no docker CLI, so every later docker command failed on a host that otherwise looked correctly installed.

The cause is weak dependencies. Every docker-ee package on repos.mirantis.com declares its companions as recommended packages (rpm Recommends / deb Recommends), never as hard Requires/Depends — verified across rhel 8/9, sles 15 and ubuntu jammy/noble on both stable-25.0 and stable-29.2:

RECOMMENDNAME:
  cri-dockerd-ee
  docker-ee-cli

Package managers install recommended packages by default, which is why the CLI normally appears without launchpad naming it. Hardening baselines commonly disable that — install_weak_deps=false (dnf/yum), APT::Install-Recommends "false" (apt), solver.onlyRequires (zypper).

The CLI is not the whole gap. cri-dockerd-ee is also only a recommended package, and launchpad never installs it explicitly anywhere — it only references cri-dockerd-mke.service/.socket during cleanup. On the same hosts, the Kubernetes CRI shim is missing too. Addressing the mechanism covers both; naming the CLI covers only the package that happened to be noticed.

How

spec.mcr.installRecommends maps to each manager's own opt-in:

Manager	Argument added
yum/dnf	--setopt=install_weak_deps=True
apt-get	-o APT::Install-Recommends=true
zypper	--recommends

Which packages that installs is decided by repository metadata, not by launchpad, so the list cannot drift.

rig's InstallPackage hardcodes <manager> install -y <packages> and accepts no further arguments. SLES already bypassed it with a direct command for --allow-vendor-change (PRODENG-3623). Rather than adding two more ad-hoc bypasses, all three commands are now built in one place — configurer.MCRInstallCommand — and covered by a single table test.

Default behaviour is unchanged. With the flag unset the generated commands are byte-identical to what rig ran:

yum install -y docker-ee
DEBIAN_FRONTEND=noninteractive apt-get install -y -q docker-ee
zypper -n install -y --allow-vendor-change docker-ee

The -q on apt is there because rig had it; the tests assert that equivalence, which is how I caught its omission in the first draft. rig also ran apt-get update inside InstallPackage, which InstallMCR already does explicitly beforehand, so it is not repeated.

Trade-off versus the alternative

• This PR: delegates the package set to repository metadata so it cannot drift, and covers cri-dockerd-ee as well as the CLI. Cost: the recommended set differs by platform. On rpm hosts it is exactly cri-dockerd-ee + docker-ee-cli; on deb hosts it additionally installs ca-certificates, docker-ee-rootless-extras, git, libltdl7, pigz, procps, xz-utils and a kernel (>= 4.15) package. Installing a kernel as a side effect of this flag deserves an explicit decision — it is documented on the config field. Second cost: three direct command paths instead of rig's helper.
• The installCLI PR: identical two-package behaviour everywhere and no surprising footprint, but a hardcoded list that can drift, and it leaves the cri-dockerd-ee gap unaddressed.

Testing

• TestMCRInstallCommand — table over all three managers × flag set/unset. Asserts the unset commands match rig's previous behaviour exactly, and that SLES keeps --allow-vendor-change in both cases.
• TestMCRInstallCommandUnknownManager — the error path, so an unhandled family fails loudly rather than returning an empty command that would execute as a no-op.
• TestMCRConfig_InstallRecommends — the yaml key round-trips (absent → false, true/false honoured).
• Confirmed discriminating: with the flag condition neutered, exactly the three opt-in cases fail and the three default cases still pass.
• 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. The --setopt spelling was verified against dnf directly; the apt and zypper spellings were verified against their manpages, not on a live host.

Note on scope

If MKE genuinely requires cri-dockerd-ee, obtaining it via a weak dependency is arguably a latent bug in its own right, independent of this flag and of the CLI question. Worth a separate ticket either way.

Links

• JIRA: PRODENG-3641

Written by AI: claude-sonnet-5