-
Notifications
You must be signed in to change notification settings - Fork 59
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
How to ship cloud specific bits #41
Comments
are there examples of varying cloud configs that will be needed? |
https://github.com/coreos/coreos-overlay/tree/master/coreos-base look at the |
Shipping them in the initramfs means we're paying the unpack overhead (which, yes, is probably minor) on every boot. |
Some notes from the meeting today:
In terms of cloud-specific grub configs, I think baking them in seems like a good idea. Let the bits not in a filesystem differ and have the filesystems be the same for all clouds. |
@ajeddeloh some late feedback (sorry, yesterday in the meeting I didn't get a good understanding on this):
|
Following this trend of discussion, there is also another interesting thing we could experiment. If we ship all OEM bits in all cases, we could try to bake a single raw image and just convert it to multiple formats. In order to identify the OEM once booted, we can use few bytes outside of the filesystem (e.g. I was looking at MBR disk-signature, which is 4 bytes and unused on GPT and not covered by a checksum), inject there a numerical ID and let grub set the kernel cmdline oem-id to a well-known string based on those bytes. |
This isn't really an issue anymore. Cloud-specific logic is normally gated via systemd units or generators that check for |
Not to be confused with the discussion of agents in #12.
Clouds will need slightly different base/default Ignition configs and probably some extra config files for Ignition to use. Two questions arise: where do we ship them (initramfs?
/
?/boot
?) and how do we ship them considering there are multiple clouds?My proposal that I'm not super attached to:
/some_path/$oem_id/{base,default}.ign
or have systemd service that copys one to the location Ignition expects. Again, they aren't big and text compresses well, so it shouldn't be too much extra space used.The text was updated successfully, but these errors were encountered: