Switch to always opting into phased updates. #709
Merged
Conversation
This file contains 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
When initially installing a package, phased update percentage is not considered at all. It's only used when considering package upgrades. As a result, opting out of phased updates can create a situation where a package from the updates repository is installed during the container build in an earlier phase, but a later installation may try to install dependencies in sibling packages which are not available at the required version due to being behind the phased update percentage wall.
claraberendsen
approved these changes
Jun 5, 2023
clalancette
approved these changes
Jun 7, 2023
Test builds
|
|
This pull request has been mentioned on ROS Discourse. There might be relevant details there: https://discourse.ros.org/t/ros-infrastructure-updates-from-june-2023/32258/1 |
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.
When initially installing a package, phased update percentage is not considered at all. It's only used when considering package upgrades.
As a result, opting out of phased updates can create a situation where a package from the updates repository is installed during the container build in an earlier phase, but a later installation may try to install dependencies in sibling packages which are not available at the required version due to being behind the phased update percentage wall.
This is intended to be an alternative to #708
As of the time these tests were performed, the following was the entry for
dovecot-corein the contents of the jammy-updates repository for amd64. I picked dovecot-core because it was the first result for a phased update and doesn't have too many dependencies.Two initial base images always, and never.
In both cases, the output from
docker run ...is the sameSo empirically, the phased update configuration has no bearing on what is considered an installation candidate for an initial install. This seems overall problematic but maybe we're doing something very unusual here.
If we simulate our scenario by forcing the install of the base version of the package, we get the following pair of image builds:
Again in both cases, the output is, perhaps surprisingly, the same:
Even where phased updates are opted-out, the package is listed as upgradeable.
When running
apt upgradewe see an actual difference.Always:
Never:
One odd thing, I couldn't reproduce the behavior where an installation of a new package would fail when a set of dependencies conflicted.
I tried installing
dovecot-imapd, which had a dependency ondovecot-core (= 1:2.3.16+dfsg1-3ubuntu2.2)and in both scenarios this resulted in the version of dovecot-core getting installed.So I'm starting to suspect that this is an issue with recovering from a phased update being completely removed (as it seems the
mesaupdate has been, as of now) and that nothing we do in this configuration will actually make one jot of difference in that scenario since it does not seem that anything would allow us to recover short of completely busting the docker image cache.So this PR does not seem likely to resolve this class of error in the future.
I debated just closing it, but on balance I think that switching to opt-in for phased updates will make the image more consistent with what will actually get put on it during the build phase, and if in the future apt changes to respecting this value during initial package installation it will make it will ensure continuity of behavior.
Other controls, such as forcing a full
--no-cachebuild once in a while or catching apt issues in a post-build heuristic and retriggering after a cache purge would be potential ways to address this core problem.