manifests: Add RHEL 9.0 based RHCOS and SCOS

[travier]

Add the manifests needed to build RHEL 9.0 based RHCOS and CentOS Stream CoreOS (SCOS)

Based on #803.

# RHEL 9.0 based RHCOS
$ mkdir rhcos-rhel-9.0 && cd rhcos-rhel-9.0 && cosa init https://github.com/travier/os -b scos rhel-9.0

# CentOS Stream CoreOS (SCOS)
$ mkdir scos && cd scos && cosa init https://github.com/travier/os -b scos c9s

[travier]

/hold

[LorbusChris]

@travier I'm not sure if the setenforce 0 service for SCOS was intended to be included here, but if it was, could you split it out into a separate commit and add some justification as to why it is required?

[HuijingHei]

@travier I'm not sure if the setenforce 0 service for SCOS was intended to be included here, but if it was, could you split it out into a separate commit and add some justification as to why it is required?

Refer to https://bugzilla.redhat.com/show_bug.cgi?id=1988164, it would be better to add the bug link to track the issue

[HuijingHei]

Get following error, maybe need to fix this first
"CONFLICT (distinct types): manifest.yaml had different types on each side; renamed one of them so each can be recorded somewhere.\nAutomatic merge failed; fix conflicts and then commit the result."

[cgwalters]

Overall looks good to me.

Re the symlink swap thing though... see coreos/coreos-assembler#1459

[jlebon]

Instead of having to update the symlink (which dirties the git repo), we could put it in a subdirectory, e.g. scos/ where scos/manifest.yaml is a symlink to ../manifest-scos.yaml. Then we can use cosa init's support for subdirectories.

[HuijingHei]

/retest

[travier]

Instead of having to update the symlink (which dirties the git repo), we could put it in a subdirectory, e.g. scos/ where scos/manifest.yaml is a symlink to ../manifest-scos.yaml. Then we can use cosa init's support for subdirectories.

I've tried that in the latest commit. Not sure it's a great option. It emphasizes making two different cosa init working dir to build both RHCOS and SCOS when I would prefer we push for building both from a single cosa init to make testing a change for both easier. It would also only be used by the CI as swapping the symlink is still the easier option locally. I'm starting to think that we should revive the variant work from Colin.

[travier]

coreos/coreos-assembler#2802

Will have to be retried once the above PR made its way into a new cosa build.

[cgwalters]

It emphasizes making two different cosa init working dir to build both RHCOS and SCOS when I would prefer we push for building both from a single cosa init to make testing a change for both easier.

Hmmmm. At least personally, I have separate working directories for them. How often would one really want to build both in the same working directory? It feels weird because then what happens when you cosa run and kola run is dependent on the state of the last build. Feels like it'd make things less predictable.

This is not a really strongly held opinion but I lean a bit towards pulling off the band-aid and saying clearly: we need to do both and support both equally. And that means there shouldn't be a default. Instead, let's move the rhel bits into e.g. rhel/ and the stream bits into stream/ and require cosa init https://github.com/openshift/os rhel or cosa init https://github.com/openshift/os stream.

[travier]

Using explicit directories could be a good idea indeed. I'd say having a simple way to build both from the same checkout is useful when testing a change that will impact both instead of having to sync the change between two clones but it's not that big of a deal so I'm fine either way.

[travier]

/retest

[cgwalters]

I'd say having a simple way to build both from the same checkout is useful when testing a change that will impact both instead of having to sync the change between two clones

Ah but locally, you have that today! What I do is e.g.:
cosa init ~/src/github/openshift/os - that will use a git repository I've cloned in my standard place along with other git repos. IOW, the git repo is not actually in the builddir.

So concretely to set up both in this proposal:

for d in rhel stream; do
  mkdir $d
  (cd $d && cosa init ~/src/github/openshift/os $d)
done

And the two will share the same git checkout. If you update e.g. something in the manifest, you can do:

for d in rhel stream; do 
  (cd $d && cosa build && kola run ...)
done

to build and test both.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: cgwalters, travier

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[travier]

Needs openshift/release#29371 first

[travier]

Needs #803

[HuijingHei]

/retest

[openshift-ci]

@travier: PR needs rebase.

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.

[openshift-ci]

@travier: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/build-test-qemu	9594913	link	true	/test build-test-qemu
ci/prow/test-in-cluster	10365d0	link	false	/test test-in-cluster
ci/prow/scos-9-build-test-qemu	1d8463d	link	true	/test scos-9-build-test-qemu
ci/prow/rhcos-90-build-test-qemu	1d8463d	link	true	/test rhcos-90-build-test-qemu
ci/prow/validate	1d8463d	link	true	/test validate
ci/prow/scos-9-build-test-metal	1d8463d	link	true	/test scos-9-build-test-metal
ci/prow/rhcos-90-build-test-metal	1d8463d	link	true	/test rhcos-90-build-test-metal
ci/prow/rhcos-86-build-test-metal	1d8463d	link	true	/test rhcos-86-build-test-metal
ci/prow/rhcos-86-build-test-qemu	1d8463d	link	true	/test rhcos-86-build-test-qemu

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.

[travier]

Closing in favor of #854