[PRODENG-3623] Allow vendor change when installing MCR packages on SLES - #652
Merged
Conversation
SLES cloud images (e.g. SUSE's SLES 15 SP7 AMIs) ship a SUSE-vendor containerd package pre-installed. The Mirantis containerd.io package set must obsolete/replace it, which zypper treats as a vendor change and refuses to perform non-interactively without --allow-vendor-change -- it silently cancels and exits non-zero, surfacing as 'package manager could not install containerd.io'. Replace the generic InstallPackage calls in the SLES InstallMCR path with direct zypper installs that pass --allow-vendor-change, and wrap the underlying zypper error (%w) so future failures are diagnosable. Reproduced on a standalone SLES 15 SP7 instance against both stable-25.0 and stable-29.2; --allow-vendor-change resolves both. Written by AI: claude-sonnet-5
Note in-code that the direct-zypper workaround bypasses rig's InstallPackage only until k0sproject/rig#417/#418 land and are vendored, at which point it should revert to the generic path (or rig's opt-in option). Written by AI: claude-sonnet-5
There was a problem hiding this comment.
Pull request overview
Implements an interim SLES-specific workaround in Launchpad’s SLES host configurer to ensure MCR installation succeeds when the Mirantis containerd.io package replaces a preinstalled SUSE-vendor containerd (vendor-change scenario).
Changes:
- Replaces SLES
InstallPackagecalls forcontainerd.io/docker-eewith directzypperinstalls using--allow-vendor-change. - Adds an explicit
zypper refreshstep and improves install error diagnostics by wrapping underlying errors (%w).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Pass -n to zypper refresh so an unattended SSH run cannot block on a repo/GPG trust prompt, matching the -n install calls that follow. Addresses PR review feedback. Written by AI: claude-sonnet-5
The committed .terraform.lock.hcl pinned hashicorp/aws 6.43.0, but the provision-aws module tree now requires aws >= 6.56.0. terraform init (non-upgrade, as CI runs it) cannot reconcile the pin against the constraint and fails with 'Failed to query available provider packages' -- which terratest misreports as a transient network error and retries until the job dies. This blocks every smoke-test job, not just SLES. Regenerate the lock (aws 6.57.1) across linux_amd64/arm64 and darwin_amd64/arm64 so init resolves without --upgrade on CI and dev machines alike (the previous lock only carried a single platform's hashes). Written by AI: claude-sonnet-5
james-nesbitt
pushed a commit
that referenced
this pull request
Aug 4, 2026
Rebased onto main. Resolved the SLES InstallMCR conflict to retain the --allow-vendor-change fix (PRODENG-3623 / #652) expressed in rig v2's API. Build/test fixes required by the migration: go.mod/go.sum tidied for github.com/k0sproject/rig/v2, validate_facts_test.go updated to rig v2 CompositeConfig/ssh.Config, and %w error wrapping in the EL/SLES/Ubuntu configurers. Adds TestUpgradeModernClusterFromLegacy. Signed-off-by: Kimmo Lehto <kimmo.lehto@gmail.com> Written by AI: claude-sonnet-5
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Interim workaround: on SLES, install the MCR packages (
containerd.io,docker-ee) with a directzypper -n install -y --allow-vendor-changecall instead of the genericInstallPackagehelper, so the install succeeds on SLES cloud images that ship a distro-vendorcontainerdpre-installed.Why
On current SUSE SLES 15 cloud images,
containerdis pre-installed from SUSE. The MCRcontainerd.iopackage set obsoletes/replaces it, which zypper treats as a vendor change;zypper install -yrefuses that non-interactively and exits 4, surfacing aspackage manager could not install containerd.io. Reproduced on SLES 15 SP7 against bothstable-25.0andstable-29.2;--allow-vendor-changeresolves both.Why this is a workaround, not the final fix
The root cause is in the package-manager layer, not in launchpad:
zypper install -yshould allow the vendor change. That belongs ink0sproject/rig, whose zypper provider builds the install command. I've raised it upstream:That upstream change is an RFC (open question on whether
--allow-vendor-changeshould be a default or an opt-in option) and, even if accepted, won't land + tag + get vendored into launchpad in time for the v1.5.18 release. So this PR takes the direct-zypper workaround in the SLES configurer as the interim fix, deliberately bypassing rig'sInstallPackagefor exactly the calls that need the flag.Once the rig change lands and is vendored, this workaround should be revisited — reverted back to the generic
InstallPackagepath (if rig makes it the default) or switched to rig's opt-in option (if that's the shape maintainers choose). Tracking that follow-up under PRODENG-3623 / the upstream PR.How
InstallPackagecalls in the SLESInstallMCRpath withzypper -n refresh+zypper -n install -y --allow-vendor-change <pkg>(preserving the prior refresh behaviour, non-interactive throughout).%wso future package failures are diagnosable rather than swallowed.Testing
Validation was manual/integration only — this path runs live
zypperagainst a SLES host and has no unit coverage in-repo (nor did the code it replaces). No automated tests were added or updated.go build ./pkg/configurer/...,go vet ./pkg/configurer/sles/..., andgofmtare clean.--allow-vendor-change-> exit 0) on a standalone SLES 15 SP7 EC2 instance for bothstable-25.0andstable-29.2.smoke-modern).Links
Checklist
Written by AI: claude-sonnet-5