container-native CoreOS release engineering #828
Comments
|
To elaborate a bit, there's just one issue left on the 0.1 milestone for the rehydrator: cgwalters/coreos-diskimage-rehydrator#3 After that, I think we could consider basically polishing it and ship it. I'd like to work on cgwalters/coreos-diskimage-rehydrator#4 which would help shrink the the image down by probably 1GiB but that's a lot more involved. |
|
From a user perspective, this wouldn't affect existing functionality, right? We'd still ship the existing artifacts and stream metadata; this would just be an alternative for those who want to obtain multiple artifacts efficiently. |
|
A couple of things that I really like about this plan:
So 💯 let's do this |
|
Currently, this proposal does not call for changes in e.g. coreos-assembler. We would continue to build e.g. the The dehydrator is glued on at the end of all that - using the stream metadata, deduplicate the images. This is in a mostly naive way, without e.g. mounting them or knowing anything about ostree/ignition or even much about coreos-assembler at all. That said, there are definitely possibilities to do things along the lines that you're talking about - better splitting up the ostree build from "generate all the disk images" would indeed be very valuable I think. But it also seems orthogonal to this proposal as is right? That said...one thing we absolutely could implement is a flow that takes |
|
That also said, I think in order to make significant further improvements to the dehydrator it's likely that some changes to coreos-assembler and our build flow would be required. See cgwalters/coreos-diskimage-rehydrator#4 |
The inevitable followup to coreos#2278 that I was too cowardly to do at the time. But it's time to admit the 2 months or so of work on this was wasted. We have too much tech debt and this is a large chunk of C/C++ code that touches everything in the codebase in a nontrivial way. Bigger picture, I'm going to work on coreos/fedora-coreos-tracker#828 which will strongly orient rpm-ostree towards the container world instead. We'll still obviously keep the rpm package world around, but only as a secondary layer. What rojig was trying to do in putting "images" inside an RPM was conflating layers. It would have had a lot of benefits probably if we'd truly pushed it over the edge into completion, but that didn't happen. Let's focus on containers instead. There's still a lot more rojig code to delete but this first patch removes the bulk of it. Touching everything that references e.g. `RPMOSTREE_REFSPEC_TYPE_ROJIG` etc. can come as a 3rd phase.
The inevitable followup to coreos#2278 that I was too cowardly to do at the time. But it's time to admit the 2 months or so of work on this was wasted. We have too much tech debt and this is a large chunk of C/C++ code that touches everything in the codebase in a nontrivial way. Bigger picture, I'm going to work on coreos/fedora-coreos-tracker#828 which will strongly orient rpm-ostree towards the container world instead. We'll still obviously keep the rpm package world around, but only as a secondary layer. What rojig was trying to do in putting "images" inside an RPM was conflating layers. It would have had a lot of benefits probably if we'd truly pushed it over the edge into completion, but that didn't happen. Let's focus on containers instead. There's still a lot more rojig code to delete but this first patch removes the bulk of it. Touching everything that references e.g. `RPMOSTREE_REFSPEC_TYPE_ROJIG` etc. can come as a 3rd phase.
This will be needed for coreos/fedora-coreos-tracker#828 so coreos-assembler can find the commit it imported.
This will be needed for coreos/fedora-coreos-tracker#828 so coreos-assembler can find the commit it imported.
|
No updates to this recently. I think it's not a bad idea, but will it prove valuable enough to maintain over time in parallel to stream metadata? Not sure. In any case I think #812 is a lot more valuable and so I'm focusing on that first. |
|
I had a chat with Alex Flom around this and https://discussion.fedoraproject.org/t/oci-based-host-provisioning-baremetal-virt/36034 One thing that became clear to me - OCI artifacts are the thing that should be replacing our custom "images stored in s3 with metadata" and stream metadata longer term. It's possible today for an OCI artifact to reference other artifacts, as well as container images. Then it seems clear to me that e.g. we have an OCI artifact |
This builds on #812
Basically the idea here is we ship two container images:
quay.io/coreos/fedora-coreos:stable(see above issue)quay.io/coreos/fedora-coreos-images:stable(new)Where
fedora-coreos-imagesis a new container that would use https://github.com/cgwalters/coreos-diskimage-rehydratorFor the images, we would continue releasing stream metadata. However, the pipeline would be changed to invoke the
coreos-diskimage-rehydrator build dehydrateafter stream metadata was published, and push that as an updatedfedora-coreos-imagescontainer.An example benefit to FCOS users is making it ergonomic for users to mirror the OS along with the rest of their container images. Anyone who wants to deploy on e.g. disconnected OpenStack can just pull container images.
Also, by encapsulating our disk images in a container we can start making use of e.g. container image signing which would address #774 for example.
More generally the benefit to us is that we consistently live and breathe container images. Our CI tooling would become more oriented around that, etc.
The text was updated successfully, but these errors were encountered: