ignition-setup-user: Copy config directly into /run/ignition.json

[cgwalters]

First, copying into /usr just feels wrong; ideally even in
the initramfs /usr should be read-only.

Second, doing it this way will help with future work for
detecting the cases in which a config is provided; see:
coreos/ignition#948

[cgwalters]

I think this worked, I did a build with it and used cosa kola testiso -PS but I'm going to rd.break and be doubly sure.

[bgilbert]

Writing directly to /run/ignition.json overrides any postprocessing Ignition might want to do on the config, e.g. converting it to the latest spec version.

However, it might make sense to switch from /usr/lib/ignition to some other directory. The original idea was that /usr/lib/ignition is supplied by the distro, via whatever mechanism it wants, and Ignition just reads the directory for configs. That model predates the introduction of ignition-dracut as a centralized set of wrappers. Maybe we should switch to something in /var?

[cgwalters]

There's already a file provider and as far as I can tell since the default directory should be /, it may Just Work to delete this line? If not, we could

echo IGNITION_CONFIG_FILE=/config.ign >> /run/ignition.env

or so anyways.

[bgilbert]

The file provider is intended for testing, e.g. the blackbox tests.

What problem are you trying to solve?

[cgwalters]

What problem are you trying to solve?

coreos/ignition#948

[bgilbert]

Sure, so you said. But how does avoiding the copy into /usr help with that?

[cgwalters]

But how does avoiding the copy into /usr help with that?

Because this way it will go through the file provider, and my patch is then using that to detect "config explicitly provided". If we kept this code as is we'd need to teach the system provider to distinguish in this case between user.ign and base.ign, which feels less clean.

[bgilbert]

Because this way it will go through the file provider, and my patch is then using that to detect "config explicitly provided". If we kept this code as is we'd need to teach the system provider to distinguish in this case between user.ign and base.ign, which feels less clean.

I guess I don't see it. The distinction you're trying to make is exactly the one between user.ign and base.ign, so why not just make that distinction? The system provider provides two separate functions to fetch those two configs, and they're called from different places in engine.go, so it seems like an easy distinction to make. Either acquireConfig() produces a result or it doesn't. It seems like you're doing a lot of extra work to change where files are stored and what providers are used to fetch them.

[cgwalters]

I guess I don't see it. The distinction you're trying to make is exactly the one between user.ign and base.ign, so why not just make that distinction?

You're right that that would be sufficient to solve the default Live ISO case.

But I am trying to generalize this a bit; for example; if one manually types an ignition.config.url by pressing TAB on the Live ISO prompt, we still want networking.

And more generally, I'd like to hook things up so that on platforms that support fetching Ignition without network, we eventually solve the original issue and only enable networking in the initramfs if we detect that the Ignition config uses remote includes.

[bgilbert]

Sure, I understand the high-level goal. But I'm still not clear how this PR helps with it.

[jlebon]

Right, I think trying to solve the "conditional networking" issue at the provider level is not the way because of what Benjamin and I mentioned in coreos/ignition#948.

We need to make changes to Ignition itself for this.