-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for minimal ISO packing/unpacking #559
Conversation
I'd like to voice support for this on behalf of the Bare Metal IPI team. The requirement for this minimal ISO came about because some hardware has an actual size limit for virtual media. This is why the Assisted Installer people implemented this on their side, but that leaves any BM IPI deployments without this ability. Having this in the coreos-installer will let both workflows share the code and handle the same hardware limitations. |
Worth summarizing on some of the points in coreos/fedora-coreos-tracker#661:
Some commentary:
This is true, though if there are legitimate and not uncommon environments which cannot have their needs met with our current approaches, then the choice is really between us providing a supported path forward or them figuring it out on their own, possibly doing unsupported things in the process.
This is worth considering because I think it could also help with coreos/fedora-coreos-tracker#399.
Yes, this is true. Network kargs are terrible and may not cover all use cases, so this would really want something like #545 which would allow defining network configs a single time as NM keyfiles and embedded into the ISO.
Another way to look at this then I guess is that this is the tool we provide to do this. Also shout-out to @dustymabe who actually suggested exactly this functionality early on. Totally missed that before. |
RHCOS originally shipped coreos-installer in the initramfs and we moved away from doing that, for a few reasons:
I'd rather we solve coreos/fedora-coreos-tracker#399 in a different way. |
I'm in favor of this generally. Though we also ship a ton of pre-generated artifacts and adding this new small one doesn't seem like a big deal either to me. |
We discussed this in the meeting today. Overall there wasn't strong objections, but @bgilbert mentioned that if the problems are real, maybe we should simply ship the minimal ISO as a bona fide artifact. This would make the code here less necessary (though it's still handy to be able to extract the minimal ISO and |
To copy/paste IRC: <dustymabe> walters: considering the rehydrator - i wonder if we could get the same functionality just all using coreos-installer and embedded osmets |
here's a comment I made in the meeting and was asked to add to the ticket:
|
I think that's a valid point. IOW, the use case is not common enough to warrant a full artifact and everything it entails (including potentially inducing confusion), but common enough for us to provide tools for it. Two other points I'll bring up:
|
Yeah, I find this part persuasive. |
coreos-installer iso uproot
coreos-installer iso uproot
Dropping |
Hi folks! Will the minimal ISO be customizable via https://coreos.github.io/coreos-installer/iso-embed-ignition/ or will the only customization option be providing an ignition URL? I'm thinking about environments where DHCP is not available. |
Yes, embedding Ignition configs and modifying kargs will still be possible with the minimal ISO. |
This switch enables the new minimal ISO packing feature (see coreos/coreos-installer#559). Once a coreos-installer version with miniso support is present in RHCOS and FCOS, we can make it unconditional and drop the switch. For now, this will allow testing in the coreos-installer upstream CI.
coreos-installer iso uproot
OK, updated this now and ready for review! Requires: #635 This is still missing the last bit, which is supporting a |
\o/ Is there a way to test this PR now or does it require any changes to published images (the miniso data file)? |
Yes, it requires coreos/coreos-assembler#2466. |
This switch enables the new minimal ISO packing feature (see coreos/coreos-installer#559). Once a coreos-installer version with miniso support is present in RHCOS and FCOS, we can make it unconditional and drop the switch. For now, this will allow testing in the coreos-installer upstream CI.
This switch enables the new minimal ISO packing feature (see coreos/coreos-installer#559). Once a coreos-installer version with miniso support is present in RHCOS and FCOS, we can make it unconditional and drop the switch. For now, this will allow testing in the coreos-installer upstream CI.
This switch enables the new minimal ISO packing feature (see coreos/coreos-installer#559). Once a coreos-installer version with miniso support is present in RHCOS and FCOS, we can make it unconditional and drop the switch. For now, this will allow testing in the coreos-installer upstream CI.
🎉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great! Minor nits/cleanups, plus two issues: extract will fail on a hash mismatch if the full ISO has an embedded config or kargs, and iso kargs reset
on the minimal ISO will reinstate coreos.liveiso
.
Prep for calling it in a future patch.
Updated for comments! |
This matches the latest syntax supported by coreos/coreos-installer#559.
Requires: coreos/coreos-assembler#2543 |
This matches the latest syntax supported by coreos/coreos-installer#559.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Just some minor fixes/nits.
Prep for using it in a future patch.
Prep for using it in a future patch.
This command allows packing into the live ISO a minimal version of itself which does not contain the root squashfs. The use case for minimal ISOs has come up multiple times, notably in: coreos/fedora-coreos-tracker#661 This is a sort of intermediate approach where we don't officially ship a new artifact, but allow users to derive the minimal ISO from the official live ISO. The way this works is similar to osmet. It requires a "packing" step at build time which adds an osmet-like file (the miniso data file) on the full ISO itself. The data file describes how to construct a minimal ISO from the full ISO. It weighs in at a few kilobytes, so the impact of the size of the live ISO is negligible. If we ever officially do ship a minimal ISO, it also allows for the possibility of matching its checksum exactly. The method should be arch-independent and does not rely on e.g. modifying ISO9660 structures or moving the GPT backup header, etc... We support a `--rootfs-url` option which uses the `iso kargs` code to inject `coreos.live.rootfs_url` since that's the primary use case. That way, the minimal ISO can be prepared in a single step. One of the primary goals is to ideally satisfy the needs of the Assisted Installer (https://github.com/openshift/assisted-installer), though there's more things needed before we get there (notably #545).
Updated! |
matches, | ||
skipped, | ||
written, | ||
written_compressed, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was really tempted to return a struct like XzPackStats
or something here to group these loose return values. But... let's just keep that as a follow-up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎈 🎉 🎆
This command allows packing into the live ISO a minimal version of
itself which does not contain the root squashfs. The use case for
minimal ISOs has come up multiple times, notably in:
coreos/fedora-coreos-tracker#661
This is a sort of intermediate approach where we don't officially ship a
new artifact, but allow users to derive the minimal ISO from the
official live ISO.
The way this works is similar to osmet. It requires a "packing" step at
build time which adds an osmet-like file (the miniso data file) on the
full ISO itself. The data file describes how to construct a minimal ISO
from the full ISO. It weighs in at a few kilobytes, so the impact of the
size of the live ISO is negligible. If we ever officially do ship a
minimal ISO, it also allows for the possibility of matching its checksum
exactly.
The method should be arch-independent and does not rely on e.g.
modifying ISO9660 structures or moving the GPT backup header, etc...
We'll want to also add a
--rootfs-url
which uses theiso kargs
codeto inject
coreos.live.rootfs_url
since that's the primary use case soit can all be done in a single step.
One of the primary goals is to ideally satisfy the needs of the Assisted
Installer (openshift/assisted-installer), though
there's more things needed before we get there (notably #545).