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

OEM configs are hardcoded in Ignition #2004

Closed
bgilbert opened this Issue Jun 15, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@bgilbert
Member

bgilbert commented Jun 15, 2017

Issue Report

Feature Request

Environment

Several

Desired Feature

OEM-specific configs are currently hardcoded in Ignition. Move them to files in the OEM partition, and provide a way for the OS to signal Ignition that it should read an additional config file there.

Other Information

@crawford

This comment has been minimized.

Show comment
Hide comment
@crawford

crawford Jun 16, 2017

Member

One possibility is to add another flag to Ignition that signals that a local file should be used as the base config. Then when we invoke Ignition in the initramfs, we'd mount the OEM partition, and pass along the file (if it exists) via the flag.

Member

crawford commented Jun 16, 2017

One possibility is to add another flag to Ignition that signals that a local file should be used as the base config. Then when we invoke Ignition in the initramfs, we'd mount the OEM partition, and pass along the file (if it exists) via the flag.

@bgilbert bgilbert self-assigned this Sep 17, 2017

@bgilbert

This comment has been minimized.

Show comment
Hide comment
@bgilbert

bgilbert Sep 21, 2017

Member

@crawford The options as I see them:

  1. Have the initramfs mount the OEM partition, run ignition --base-config /path/to/OEM/base.ign, and unmount afterward. This won't work for the disks stage, since sgdisk doesn't know how to force the kernel to reread sda's partition table if any sda partition is mounted.
  2. Have the initramfs mount the OEM partition, copy out the base and default configs, unmount, and then run Ignition. That could work, but the mount and umount would have to be scripted rather than using mount units, since a unit can't be started and stopped in the same transaction.
  3. Use Ignition's existing oem:/// URL support to mount the OEM partition and read out a base.ign and default.ign. Downside 1: the resource code really wants to mount the OEM partition once per resource, which is non-trivial to fix. Downside 2: on PXE systems there isn't an OEM partition. A fix for the latter is to check /run/oem after /usr/share/oem, and have bootengine create /run/oem/{base,default}.ign when /usr.squashfs exists, but that's kind of hacky.
  4. Move the base configs into bootengine rather than into the OEMs, which is still an improvement over the status quo.

I'm currently pursuing approach 3, but it's not entirely pretty. Thoughts?

Member

bgilbert commented Sep 21, 2017

@crawford The options as I see them:

  1. Have the initramfs mount the OEM partition, run ignition --base-config /path/to/OEM/base.ign, and unmount afterward. This won't work for the disks stage, since sgdisk doesn't know how to force the kernel to reread sda's partition table if any sda partition is mounted.
  2. Have the initramfs mount the OEM partition, copy out the base and default configs, unmount, and then run Ignition. That could work, but the mount and umount would have to be scripted rather than using mount units, since a unit can't be started and stopped in the same transaction.
  3. Use Ignition's existing oem:/// URL support to mount the OEM partition and read out a base.ign and default.ign. Downside 1: the resource code really wants to mount the OEM partition once per resource, which is non-trivial to fix. Downside 2: on PXE systems there isn't an OEM partition. A fix for the latter is to check /run/oem after /usr/share/oem, and have bootengine create /run/oem/{base,default}.ign when /usr.squashfs exists, but that's kind of hacky.
  4. Move the base configs into bootengine rather than into the OEMs, which is still an improvement over the status quo.

I'm currently pursuing approach 3, but it's not entirely pretty. Thoughts?

@crawford

This comment has been minimized.

Show comment
Hide comment
@crawford

crawford Sep 21, 2017

Member

Hmm, I'm stuck between 2 and 3. On one hand, I think 2 works very well for our system since we know that configs will always come from one of two locations (depending on whether or not we are PXE booting). On the other, 3 is much more flexible and allows others to potentially pull base configs from network locations.

I'm not clear on downside 1 though. I thought the resource code unmounted right after reading the file. As for downside 2, can't we use conditional drop-ins that key on coreos.oem.id to change the flag?

Member

crawford commented Sep 21, 2017

Hmm, I'm stuck between 2 and 3. On one hand, I think 2 works very well for our system since we know that configs will always come from one of two locations (depending on whether or not we are PXE booting). On the other, 3 is much more flexible and allows others to potentially pull base configs from network locations.

I'm not clear on downside 1 though. I thought the resource code unmounted right after reading the file. As for downside 2, can't we use conditional drop-ins that key on coreos.oem.id to change the flag?

@bgilbert

This comment has been minimized.

Show comment
Hide comment
@bgilbert

bgilbert Nov 16, 2017

Member

Downside 1 is just an objection to mounting and unmounting the OEM partition once for each file we read from it. As to downside 2, we could use conditional dropins, but that also seems kind of hacky.

I've now abandoned option 3 as too complex. coreos/ignition#475 implements the Ignition part of option 2.

Member

bgilbert commented Nov 16, 2017

Downside 1 is just an objection to mounting and unmounting the OEM partition once for each file we read from it. As to downside 2, we could use conditional dropins, but that also seems kind of hacky.

I've now abandoned option 3 as too complex. coreos/ignition#475 implements the Ignition part of option 2.

@bgilbert

This comment has been minimized.

Show comment
Hide comment
@bgilbert

bgilbert Dec 12, 2017

Member

Done upstream; pending Ignition release.

cc @dgonyeo

Member

bgilbert commented Dec 12, 2017

Done upstream; pending Ignition release.

cc @dgonyeo

@bgilbert

This comment has been minimized.

Show comment
Hide comment
Member

bgilbert commented Dec 15, 2017

@bgilbert bgilbert closed this Dec 15, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment