kola: Change --oscontainer to use new ostree native containers
#3004
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
Quite a while ago we added this special case code to kola which learned how to do in-place updates to the weird bespoke "ostree repo in container" OCP/RHCOS-specific container image. A huge benefit of the change to use ostree-native containers is that this approach can now be shared across FCOS/RHCOS. (Also, rpm-ostree natively understands this, so it's much much more efficient and less awkward than the wrappers we had in `pivot` around rpm-ostree) But the benefits get even larger: this issue: coreos#2685 proposes rethinking of our pipeline to more cleanly split up "build OS update container" from "build disk images". With this, it becomes extra convenient to do a flow of: - build OS update container, push to registry - `kola run -p stable --oscontainer quay.io/fcos-devel/testos@sha256...` IOW we're not generating a disk image to test the OS update - we're using the *stable* disk image and doing an in-place update before we run tests. Now...as of right now nothing in the pipeline passes this flag, so the code won't be used (except for manual testing). Suddenly with this, the number of tests we can run roughly *doubles*. For example, we can run e.g. `kola run rpm-ostree` both with and without `--oscontainer`. In most cases, things should be the same. But, I think it will be interesting to try to explictly use this for at least some tests; it's almost a full generalization of the `kola run-upgrades` bits.
|
Here's a new flow possible: IOW - build as a container, natively using container tools (no coreos-assembler involved) and test the resulting container in AWS (or on any of our platforms) using any of our existing tests. |
prestist
reviewed
Jul 27, 2022
prestist
approved these changes
Jul 27, 2022
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.
Quite a while ago we added this special case code to kola
which learned how to do in-place updates to the weird bespoke
"ostree repo in container" OCP/RHCOS-specific container image.
A huge benefit of the change to use ostree-native containers
is that this approach can now be shared across FCOS/RHCOS.
(Also, rpm-ostree natively understands this, so it's much much
more efficient and less awkward than the wrappers we had in
pivotaroundrpm-ostree)
But the benefits get even larger: this issue:
#2685
proposes rethinking of our pipeline to more cleanly split up
"build OS update container" from "build disk images".
With this, it becomes extra convenient to do a flow of:
kola run -p stable --oscontainer quay.io/fcos-devel/testos@sha256...IOW we're not generating a disk image to test the OS update - we're
using the stable disk image and doing an in-place update before
we run tests.
Now...as of right now nothing in the pipeline passes this flag,
so the code won't be used (except for manual testing).
Suddenly with this, the number of tests we can run roughly doubles.
For example, we can run e.g.
kola run rpm-ostreeboth with and without--oscontainer.In most cases, things should be the same. But, I think it will
be interesting to try to explictly use this for at least some tests;
it's almost a full generalization of the
kola run-upgradesbits.