You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Branching is when a new stream is "branched" off of rawhide. This eventually becomes the next major Fedora (N).
Release engineering changes
Verify that a few tags were created when branching occurred:
f${N+1}-coreos-signing-pending
f${N+1}-coreos-continuous
Add and tag a package (any package) which is in the stable repos into the continuous tag. This will create the initial yum repo that's used as input for building the COSA container.
koji add-pkg --owner ${FAS_USERNAME} f${N+1}-coreos-continuous $PKG
example: koji add-pkg --owner dustymabe f36-coreos-continuous fedora-release
This example uses the fedora-release RPM, but it could be any other.
koji tag-build f${N+1}-coreos-continuous $BUILD
example: koji tag-build f36-coreos-continuous fedora-release-36-0.16
Add the N+1 signing key short hash (usually found here) to the tag info for the coreos-pool tag. The following commands view the current settings and then update the list to the 32/33/34/35 keys. You'll most likely have to get someone from releng to run the second command (edit-tag).
koji taginfo coreos-pool
koji edit-tag coreos-pool -x tag2distrepo.keys="12c944d0 9570ff31 45719a39 9867c58f"
coreos-installer changes
Update coreos-installer to know about the signing key used for the future new major version of Fedora (N+1).
Disable branched stream since it is no longer needed.
Update config.yaml to comment out the branched stream definition.
Ship rebased next
Ship next
Set a new update barrier for the final release of N-1 on next. In the barrier entry set a link to the docs. See discussion
Preparing for Fedora (N) GA
Do these steps as soon as we have a Go confirmation for GA, usually the Thursday of the week before GA.
Ship a final next release
If the packages in next-devel don't exactly match the last next release that was done, we need to do a release with the final GA content. This ensures that what we'll promote to testing has the exact content in GA (plus version fast-tracks). This usually happens on the Thursday of the announcement of Go.
Ensure final next release has GA content
Build rebased testing and final stable release on N-1
Build stable; promote it from the testing branch, which should still be on N-1. Don't release it yet (i.e. don't run the release job).
Build testing; promote it from the next branch instead of testing-devel. Don't release it yet (i.e. don't run the release job).
Bump the base Fedora version in ci/buildroot/Dockerfile
Bump the Fedora version for the test containers in tests/kola/data/commonlib.sh
PR the result
At Fedora (N) GA
Do these steps on GA day.
Release rebased testing and final stable release on N-1
Run the release job for the staged testing and stable builds and start rollout.
Set a new update barrier for the final release of N-1 on testing. In the barrier entry set a link to the docs. See discussion
Disable next-devel stream if not needed
We prefer to disable next-devel when there is no difference between testing-devel and next-devel. This allows us to prevent wasting a bunch of resources (bandwidth, storage, compute) for no reason. After the switch to N if next-devel and testing-devel are in lockstep, then disable next-devel.
Follow the instructions here to disable next-devel
Switch upstream packages to shipping release binaries from Fedora (N)
Remove from the manifest.yaml of next-devel the fedora-candidate-compose repo
After Fedora (N) GA
Ship rebased stable
Ship stable
Set a new update barrier for the final release of N-1 on stable. In the barrier entry set a link to the docs. See discussion
Untag old packages
koji untag N-2 packages from the pool (at some point we'll have GC in place to do this for us, but for now we must remember to do this manually or otherwise distRepo will fail once the signed packages are GC'ed). For example the following snippet finds all RPMs signed by the Fedora 32 key and untags them. Use this process:
Find the key short hash. Usually found here. Then:
f32key=12c944d0
key=$f32key
echo > untaglist # create or empty out file
for build in $(koji list-tagged --quiet coreos-pool | cut -f1 -d' '); do
if koji buildinfo $build | grep $key 1>/dev/null; then
echo "Adding $build to untag list"
echo "${build}" >> untaglist
fi
done
Now we have a list of builds to untag. But we need a few more sanity checks.
Make sure none of the builds are used in N based FCOS. Check by running:
If there are any RPMs signed by the old key they'll need to be investigated. Maybe they shouldn't be used any longer. Or maybe they're still needed. One example of this is the shim RPM where the same build could be used for many Fedora releases. In this case you'll need to untag the RPM from coreos-pool, run a koji distrepo, which will remove that RPM from the repo metadata, and then re-tag it into the pool. The RPM in the repo will now be signed with a newer signing key.
After verifying the list looks good, untag:
# use xargs so we don't exhaust bash string limit
cat untaglist | xargs -L50 koji untag-build -v coreos-pool
Now that untagging is done, give a heads up to rpm-ostree developers that N-2 packages have been untagged and that they may need to update their CI compose tests to freeze on a newer FCOS commit.
Remove the N-2 signing key from the tag info for the coreos-pool tag. The following commands view the current settings and then update the list to the 33/34/35 keys. You'll most likely have to get someone from releng to run the second command (edit-tag).
koji taginfo coreos-pool
koji edit-tag coreos-pool -x tag2distrepo.keys="9570ff31 45719a39 9867c58f"
label with FN label where N is the Fedora version.
Miscellaneous container updates
These are various containers in use throughout our ecosystem. We should update or open a ticket to track updating them once a new Fedora release is out. If you open a ticket instead of doing the update add a link to the ticket as comment.
Rebase to a new version of Fedora (N)
At previous Fedora major release
Open tickets to track related work for this release
At Branching
Branching is when a new stream is "branched" off of
rawhide
. This eventually becomes the next major Fedora (N).Release engineering changes
Verify that a few tags were created when branching occurred:
f${N+1}-coreos-signing-pending
f${N+1}-coreos-continuous
Add and tag a package (any package) which is in the stable repos into the continuous tag. This will create the initial yum repo that's used as input for building the COSA container.
koji add-pkg --owner ${FAS_USERNAME} f${N+1}-coreos-continuous $PKG
koji add-pkg --owner dustymabe f36-coreos-continuous fedora-release
fedora-release
RPM, but it could be any other.koji tag-build f${N+1}-coreos-continuous $BUILD
koji tag-build f36-coreos-continuous fedora-release-36-0.16
Add the N+1 signing key short hash (usually found here) to the tag info for the coreos-pool tag. The following commands view the current settings and then update the list to the 32/33/34/35 keys. You'll most likely have to get someone from releng to run the second command (
edit-tag
).koji taginfo coreos-pool
koji edit-tag coreos-pool -x tag2distrepo.keys="12c944d0 9570ff31 45719a39 9867c58f"
coreos-installer changes
Example PR: coreos/coreos-installer#1113
Update
rawhide
streamEnable
branched
streambranched
stream definition (example PR)At Fedora (N) Beta
Update fedora-coreos-config
next-devel
Bump
releasever
inmanifest.yaml
Add the
fedora-candidate-compose
repo inmanifest.yaml
(example PR)Update the repos in
manifest.yaml
if neededRun
cosa fetch --dry-run --update-lockfile
bump-lockfile
runs.cosa fetch
directlyPR the result
Re-enable
next-devel
if needed (docs)Disable
branched
stream since it is no longer needed.branched
stream definition.Ship rebased
next
next
next
. In the barrier entry set a link to the docs. See discussionPreparing for Fedora (N) GA
Do these steps as soon as we have a Go confirmation for GA, usually the Thursday of the week before GA.
Ship a final
next
releaseIf the packages in
next-devel
don't exactly match the lastnext
release that was done, we need to do a release with the final GA content. This ensures that what we'll promote totesting
has the exact content in GA (plus version fast-tracks). This usually happens on the Thursday of the announcement of Go.next
release has GA contentBuild rebased
testing
and finalstable
release on N-1stable
; promote it from thetesting
branch, which should still be on N-1. Don't release it yet (i.e. don't run therelease
job).testing
; promote it from thenext
branch instead oftesting-devel
. Don't release it yet (i.e. don't run therelease
job).Update fedora-coreos-config
testing-devel
releasever
inmanifest.yaml
manifest.yaml
if needednext-devel
ci/buildroot/Dockerfile
tests/kola/data/commonlib.sh
At Fedora (N) GA
Do these steps on GA day.
Release rebased
testing
and finalstable
release on N-1release
job for the stagedtesting
andstable
builds and start rollout.testing
. In the barrier entry set a link to the docs. See discussionDisable
next-devel
stream if not neededWe prefer to disable
next-devel
when there is no difference betweentesting-devel
andnext-devel
. This allows us to prevent wasting a bunch of resources (bandwidth, storage, compute) for no reason. After the switch to N ifnext-devel
andtesting-devel
are in lockstep, then disablenext-devel
.next-devel
Switch upstream packages to shipping release binaries from Fedora (N)
Disable the
fedora-candidate-compose
repomanifest.yaml
ofnext-devel
thefedora-candidate-compose
repoAfter Fedora (N) GA
Ship rebased
stable
stable
stable
. In the barrier entry set a link to the docs. See discussionUntag old packages
koji untag
N-2 packages from the pool (at some point we'll have GC in place to do this for us, but for now we must remember to do this manually or otherwise distRepo will fail once the signed packages are GC'ed). For example the following snippet finds all RPMs signed by the Fedora 32 key and untags them. Use this process:Now we have a list of builds to untag. But we need a few more sanity checks.
N
based FCOS. Check by running:If there are any RPMs signed by the old key they'll need to be investigated. Maybe they shouldn't be used any longer. Or maybe they're still needed. One example of this is the shim RPM where the same build could be used for many Fedora releases. In this case you'll need to untag the RPM from
coreos-pool
, run akoji distrepo
, which will remove that RPM from the repo metadata, and then re-tag it into the pool. The RPM in the repo will now be signed with a newer signing key.Now that untagging is done, give a heads up to rpm-ostree developers that N-2 packages have been untagged and that they may need to update their CI compose tests to freeze on a newer FCOS commit.
Remove the N-2 signing key from the tag info for the coreos-pool tag. The following commands view the current settings and then update the list to the 33/34/35 keys. You'll most likely have to get someone from releng to run the second command (
edit-tag
).koji taginfo coreos-pool
koji edit-tag coreos-pool -x tag2distrepo.keys="9570ff31 45719a39 9867c58f"
Open ticket for the next Fedora rebase
FN
label whereN
is the Fedora version.Miscellaneous container updates
These are various containers in use throughout our ecosystem. We should update or open a ticket to track updating them once a new Fedora release is out. If you open a ticket instead of doing the update add a link to the ticket as comment.
The text was updated successfully, but these errors were encountered: