-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🌱 E2e: Unhold CI packages before installing #7910
🌱 E2e: Unhold CI packages before installing #7910
Conversation
It is common to mark kubeadm and related packages as held at a specific version to avoid accidental upgrades. The script for injecting CI artifacts does not take this into account, which means that if the base image used already has some version of a package installed and held, the script will fail to install the asked for version. To avoid this, we unhold before installing the packages and then hold again, as customary. Holding after installation also avoids any unintended upgrades later.
It would be nice to get some eyes of folks from providers because they are the primary users of this script (or to bring this up to the community meeting) |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/lgtm |
LGTM label has been added. Git tree hash: f523fe75163574d4d26aeab49bf378735759f181
|
/lgtm Proposing a lazy consensus deadline for this Friday |
apt-get install -y "$${CI_PACKAGE}=$${PACKAGE_VERSION}" | ||
apt-mark hold "$${CI_PACKAGE}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably should only hold if it was held before we Unhold
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say it is safer to hold regardless. This would only be used when requesting a specific version to be installed, so holding at that version makes sense IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also a script only for CI so shouldn't matter
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fabriziopandini 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:
Approvers can indicate their approval by writing |
/area e2e-testing |
What this PR does / why we need it:
It is common to mark kubeadm and related packages as held at a specific version to avoid accidental upgrades. The script for injecting CI artifacts does not take this into account, which means that if the base image used already has some version of a package installed and held, the script will fail to install the asked for version. To avoid this, we unhold before installing the packages and then hold again, as customary. Holding after installation also avoids any unintended upgrades later.
An alternative could be to add the flag
--allow-change-held-packages
to the install command, but I think unholding is a nicer way to do it.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes kubernetes-sigs/cluster-api-provider-openstack#1429