Updates for variant & yumrepo support in COSA#958
Updates for variant & yumrepo support in COSA#958openshift-merge-robot merged 4 commits intoopenshift:masterfrom
Conversation
On top of the defaut variant, a config repo may include aditional optional variants. The variant used is selected at `cosa init` with the `--variant` option and the value is recorded locally in `src/config.json`. See: - openshift/os#852 - openshift/os#901 - openshift/os#958 Reworks: 480c239 init: Require specifying a config repository
|
I am OK with this, just confused about the |
|
Agree that this is confusing. I'll update the docs and add a note like below to explain. The idea is that we want to have a default variant (no suffix) that is the one we want to build by default when you clone the repo. Right now this is the one shipped in production (built by the pipelines) but we might want to switch to SCOS at some point. We also want explicit options to be able to work on a specific variant by specifying exact RHEL or CentOS Stream versions as variants ( But we also want to be able to track major streams/versions as we will make two pipelines, one for RHEL 8 based RHCOS and one for RHEL 9 based RHCOS (plus one for SCOS elsewhere). So we need Thus the idea behind the chain of symlinks is that we make explicit those decisions:
|
On top of the defaut variant, a config repo may include aditional optional variants. The variant used is selected at `cosa init` with the `--variant` option and the value is recorded locally in `src/config.json`. See: - openshift/os#852 - openshift/os#901 - openshift/os#958 Reworks: 480c239 init: Require specifying a config repository
On top of the defaut variant, a config repo may include aditional optional variants. The variant used is selected at `cosa init` with the `--variant` option and the value is recorded locally in `src/config.json`. See: - openshift/os#852 - openshift/os#901 - openshift/os#958 Reworks: 480c239 init: Require specifying a config repository
jlebon
left a comment
There was a problem hiding this comment.
LGTM! Thanks a lot for updating the docs.
| "rhcos-cosa-prow-pr-ci") | ||
| setup_user | ||
| cosa_init | ||
| cosa_init "rhel-coreos-8" |
There was a problem hiding this comment.
Bikeshed: WDYT about rhcos8 and rhcos9 instead? Seems closer to what we're used to type and matches the other scos better too.
There was a problem hiding this comment.
There was a problem hiding this comment.
I agree typing rhcos is more convenient in quick emails and interactive chat. But for anything a bit more formal I'd like to move to being more explicit because the world can only have so many acronyms. "rhel-coreos" is not that much longer and is much, much more self-describing, even though it still contains one acronym.
There was a problem hiding this comment.
I suppose a counterargument is the plethora of rhcos- in https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.11/latest/ ...but...we can change that.
There was a problem hiding this comment.
We've started using rhel-coreos-8 & rhel-coreos-9 for the machine-os-content & container names somewhere but I don't remember exactly where thus the change here.
There was a problem hiding this comment.
There was a problem hiding this comment.
I think my core argument here is: With the introduction of RHEL9, the abbreviation "rhcos" has become ambiguous outside of the most generic contexts. Specifically, mirror.openshift.com for example can't just use rhcos - it has to become either rhcos8 and rhcos9 as you suggest, but I think while we are renaming things, let's use rhel-coreos-8 and rhel-coreos-9 there and in our disk images in general.
There was a problem hiding this comment.
No strong argument against rhel-coreos-N, but note that RHCOS as an acronym is pretty established at this point, including in official OpenShift docs. We do need to start adding the version string, but I'm not sure it follows that we need to also change the prefix.
On top of the defaut variant, a config repo may include aditional optional variants. The variant used is selected at `cosa init` with the `--variant` option and the value is recorded locally in `src/config.json`. See: - openshift/os#852 - openshift/os#901 - openshift/os#958 Reworks: 480c239 init: Require specifying a config repository
|
I think we need to force a rebuild of the layered cosa image. /retest all |
|
@jlebon: The
Use DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/test images |
|
/retest |
1 similar comment
|
/retest |
|
CI failure looks legit now. |
On top of the defaut variant, a config repo may include aditional optional variants. The variant used is selected at `cosa init` with the `--variant` option and the value is recorded locally in `src/config.json`. See: - openshift/os#852 - openshift/os#901 - openshift/os#958 Reworks: 480c239 init: Require specifying a config repository
|
/test images |
|
/retest |
|
/test images |
|
/retest |
|
/test images |
|
/test images |
|
/test images |
To make the logic simpler, we're carrying the variant <-> version logic with symlinks in this repo See COSA support in coreos/coreos-assembler#2934
17ca171 to
60b1a8c
Compare
- Use a single kola denylist - Remove setup variant workarounds - Use an explicit variant for all test jobs - Use the variant info to fetch the right repos
|
The failing tests look like flakes to me offhand. |
|
/retest |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters, jlebon, travier The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@travier: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
manifests: Rework symlinks to match variant support in COSA
To make the logic simpler, we're carrying the variant <-> version logic
with symlinks in this repo
See COSA support in coreos/coreos-assembler#2934
manifests: Fix 'distro' variable for C9S
kola-denylist & ci: Use COSA variant support
docs: Update for variant & yumrepo support