Mark all kickstart non-RPM content as phase2 [RHELDST-28021] #760
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
rohanpm
force-pushed
the
kickstart-phase2
branch
from
d61bd25 to
5f6abde
Compare
We want to change some logic around kickstart items. Make sure the behavior is covered by tests first.
Kickstart repos don't adhere to the "mutable entry point, immutable everything else" design of other content types, such as yum and file repos. For example, files such as "/EULA", "/images/install.img" may receive in-place updates. As such, the usual categorization between phase1 and phase2 content based on entry points does not fit these repos correctly. From the point of view of exodus-gw, the set of files receiving in-place updates is arbitrary, so we'd better treat them *all* as phase 2 content and try to update them together. RPM files are the only exception, as we still expect that an RPM published to the same path is always the same thing. The effects of categorizing kickstart files as phase2 content include: - on publish, CDN cache will now be flushed for all non-RPM kickstart paths (rather than only the entry points). - on publish, non-RPM kickstart paths will be recorded into PublishedPath table, which allows them to trigger cache flush again when releasever_alias are updated in config. (This is the primary motivation for the change, as this important cache flush currently must be done manually.) - in-place updates to the repos are now more likely to appear as atomic from the customer's point of view. - kickstart publishes may be somewhat slower, as it is necessary to delay more of the publishing work until the user requests the final commit.
rohanpm
force-pushed
the
kickstart-phase2
branch
from
5f6abde to
1b675bc
Compare
negillett
approved these changes
Dec 2, 2024
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.
Kickstart repos don't adhere to the "mutable entry point, immutable
everything else" design of other content types, such as yum and
file repos. For example, files such as "/EULA", "/images/install.img"
may receive in-place updates.
As such, the usual categorization between phase1 and phase2 content
based on entry points does not fit these repos correctly.
From the point of view of exodus-gw, the set of files receiving
in-place updates is arbitrary, so we'd better treat them all as phase
2 content and try to update them together. RPM files are the only
exception, as we still expect that an RPM published to the same
path is always the same thing.
The effects of categorizing kickstart files as phase2 content include:
on publish, CDN cache will now be flushed for all non-RPM kickstart
paths (rather than only the entry points).
on publish, non-RPM kickstart paths will be recorded into
PublishedPath table, which allows them to trigger cache flush again
when releasever_alias are updated in config. (This is the primary
motivation for the change, as this important cache flush currently
must be done manually.)
in-place updates to the repos are now more likely to appear as atomic
from the customer's point of view.
kickstart publishes may be somewhat slower, as it is necessary to
delay more of the publishing work until the user requests the final
commit.