WIP: build: Add support for "variants" #1459
Conversation
My immediate goal here is to change https://github.com/cgwalters/centos-coreos-stream-config into something more like "openshift/coreos-config" that can be built in multiple ways. We'd have `rhcos` and `cscos` as "build variants". And actually while we're here potentially `rhbasecos` which would be "just stuff from RHEL". Another use case for this is the "alternative desktops" for Silverblue. And yet another use case is something like a "debug" build for FCOS where e.g. we swap in `kernel-debug` and potentially turn on other userspace debugging too.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
And another use case: I've been thinking lately that it would simplify a whole bunch of things if for RHCOS we split up "bootimage build" and "oscontainer build'. Once the bootstrap node pivots then in fact I think we could have the bootimage just be RHEL - we keep kubelet and the other bits in the oscontainer. This would make OCP/RHCOS operate the same way OKD/FCOS does. It'd also solve various "source of truth" problems where we push to both a registry and S3 - for the oscontainer the registry should be canonical. |
(Though this conflicts somewhat with the live ISO containing kubelet, but there's no reason we can't do live layering eventually) |
|
Yet another obvious use case: rather than having e.g. git branches for e.g. This gets into a whole interesting topic around the representation of the fedora-coreos-config branches and whether we should instead just use git |
Prep for variant builds: coreos#1459 This way variant builds can simply use separate filenames rather than redundantly specifying the name in the `rojig` section (which was always awkward to start with).
Prep for variant builds: coreos#1459 This way variant builds can simply use separate filenames rather than redundantly specifying the name in the `rojig` section (which was always awkward to start with).
coreos/coreos-assembler#1459 is going to add support for more convenient multiple builds. Here the `name` is derived simply from the name of the manifest file. We use the summary for cloud uploads, so that moves to `image.yaml`.
Hmm, how would this work? rpm-ostree treefile merges extend lists, which means that e.g. to swap out |
Until coreos/coreos-assembler#1459 or something like that lands, let's have this repository default to RHCOS sources.
|
@cgwalters: 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. |
|
@cgwalters: The following tests failed, say
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. |
|
Closing this one as we have merged variant support in #2934 |
My immediate goal here is to change
https://github.com/cgwalters/centos-coreos-stream-config
into something more like "openshift/coreos-config" that
can be built in multiple ways.
We'd have
rhcosandcscosas "build variants". Andactually while we're here potentially
rhbasecoswhich wouldbe "just stuff from RHEL".
Another use case for this is the "alternative desktops" for
Silverblue.
And yet another use case is something like a "debug" build
for FCOS where e.g. we swap in
kernel-debugand potentiallyturn on other userspace debugging too.