On Wed, Mar 8, 2023, at 11:20 AM, Alfredo Moralejo Alonso wrote:
As part of Cloud SIG, I think that's a good reason to look for a more appropriate (or maybe a new) SIG for this effort. Other in the ML may have ideas about other SIGs that may be a better place.
Thanks, useful to hear agreement there. That said, I am sure this SIG and Cloud would be coordinating because deployment of managed infrastructure systems (Open* and KubeVirt e.g.) and also stanadlone cloud nodes are quite important use cases for bootc. They're just not the only ones.
To xref for example we're having an interesting debate about the intersection of bootc and kubevirt over here: https://groups.google.com/g/kubevirt-dev/c/K-jNJL_Y9bA/m/ZTH78OqFBAAJ
IIUC, the expected deliverables that you have on mind for the SIG are bootc (and maybe others) rpm packages, one or more bootc container images in some official centos namespace in quay and, at some time, maybe an alternative anaconda installer or other tools with support for bootc images?
Yep, exactly! But beyond that:
- Documentation and best practices; e.g. today we have https://github.com/coreos/layering-examples but almost none of that is at all specific to "CoreOS". I should be able to run Ansible in a Dockerfile to configure my desktop system or my IoT system too that derive from CentOS 9. - CI integration is also quite important to me, I'd love to integrate with MRs to existing packages for example. An excellent example of this is https://src.fedoraproject.org/rpms/openssh/pull-request/39 where the openssh maintainer made a change which is just fundamentally incompatible with the way we do image based updates, and I'd like to make sure that "can ssh to machine after it upgrades in image mode" is a basic test run on important packages in C9S.