where to move ignition dracut modules source code

[dustymabe]

They currently live at https://github.com/dustymabe/ignition-dracut. I propose we move them somewhere more proper like the coreos org on github. Is there a better place to put it? Any issues with moving them there?

[lucab]

Sounds fine to me. Just two additional questions to pick the name before moving the repo:

• is this for FedCO only or for RHCO too?
• Do we plan to have separate repos for dracut modules or do we aggregate everything there (like bootengine)? I see we are already dumping random configs (i.e. journald) in there

[dustymabe]

is this for FedCO only or for RHCO too?

right now they are the same. Maybe if we need different ones for each we just create a separate branch?

Do we plan to have separate repos for dracut modules or do we aggregate everything there (like bootengine)? I see we are already dumping random configs (i.e. journald) in there

yeah. I'd prefer to have these be ignition specific, can we think of a good place to put other dracut modules for FCOS? i.e. these would be modules that don't belong in the rest of Fedora OR in ignition specific modules. An fcos-release package maybe?

[ajeddeloh]

I think it makes sense to have something like bootengine for FCOS (and RHCOS). There will almost certainly be differences, especially if things need to happen in the initramfs for the RHCOS bootstrapOS. I think it probably makes sense to have a "bootengine" repo for FCOS and then a fork of it for RHCOS.

I don't think the Ignition repo should include dracut modules since the Ignition dracut modules tend to be very tightly coupled to the initramfs (and have subtle dependencies on things like certain filesystems being mounted, networking, etc).

Finally, I'd like to keep the initramfs as minimal and clean as possible. If it's not 100% needed then we shouldn't include it. And we should do that from day 1, since removing things both has the potential to break things and it's really easy to put off removing things indefinitely.

[cgwalters]

Calling it bootengine-fcos or something seems fine to me, not even sure we'd need a downstream branch.

[dustymabe]

so there are three sources:

1. fedora provided (common) dracut modules/initramfs config
2. ignition dracut modules
3. other FCOS needed modules/config

Are we proposing 2. and 3. go into bootengine (never liked that name because it's not really explicit) repo/rpm ?

I like having the ignition modules separate personally, but recognize 3. is not zero (although, could it be zero if we put it into 1.?) so we'd need a 3rd source of modules, which I thought might be something we could do with a fcos-release rpm. What does Atomic Host do for this today ? Have we ever had a need?

[ajeddeloh]

Yes, we're proposing 2/3. I don't follow what you mean by a fcos-release rpm.

I'd be in favor of dropping the "bootengine" name too. I think it came from a time when having "engine" in your name was hip. It's horribly vague. maybe fcos-dracut-modules?

[lucab]

I like the fcos-dracut-modules proposal too.

Regarding the second item, do we reasonably expect ignition module to be distro-independent, so that a separate ignition-dracut makes sense? The CL and RHCOS ones already diverged, so I'm inclined to say no, in which case I would bundle everything in the above repo.

[ajeddeloh]

I agree with @lucab. That's what I meant by saying the modules are very tightly coupled with the rest of the initramfs.

[cgwalters]

fcos-dracut-modules seems sane to me.

[dustymabe]

so it seems like the concensus is to basically have two sources of dracut modules:

1. fedora provided (common) dracut modules/initramfs config
2. other FCOS needed modules/config (including ignition) in a coreos-dracut-modules package (i switched it from fcos-dracut-modules so we can possibly use the same package name in upstream and downstream)

One thing I will point out is if we move other pieces of the Fedora offerings (like the fedora cloud base image) to use ignition, we would need a separate dracut-modules rpms with ignition modules code duplicated for each offering.

[dustymabe]

i'm starting to go back and just prefer moving ignition-dracut (as it is today) to coreos/ignition-dracut-modules. Since some other distros have started to pick up and request changes I think including "coreos" in the name might be better to not do.

[dustymabe]

cc @lucab @ajeddeloh since you had discussion input above

[ajeddeloh]

I think we want cos-ignition-dracut-modules or something instead of coreos/ignition-dracut-modules. I don't think we can expect to have this bit be truly cross platform (prove me wrong?) so I think the best we can do it say "here's what we do, take it and modify it to fit your own needs. We're happy to help if you have questions."

Maybe add a note in the README with the a link explaining why coreos/bootengine is separate.

[dustymabe]

I don't think we can expect to have this bit be truly cross platform (prove me wrong?)

I'm naive and tend to be optimistic. :) Any objection to us trying?

I think if we could build in the ability to have 'common' bits and also distro specific bits into the ignition-dracut repo then it could work. So for example we have a dracut/common directory and also a dracut/fedora-coreos and dracut-suse directory. Packaging would take care of only including the directories a distro cares about for its uses. We start with everything we have today in common and then start pulling things into the separate directories when necessary.

This would require extra coordination with the other distros but would also mean we can all collaborate on the best ideas for running ignition in the initrd. I'd be interested to know what @thkukuk thinks.

Of course if this experiment failed then we could fall back to every distro maintaining separate repos.

[ajeddeloh]

I mean, there's already divergence from Container Linux. I think if we can unify *COS and CL then we have a shot, but otherwise I'm pretty pessimistic.

[thkukuk]

On Mon, Oct 29, Dusty Mabe wrote: This would require extra coordination with the other distros but would also mean we can all collaborate on the best ideas for running ignition in the initrd. I'd be interested to know what @thkukuk thinks.

Up to know, what we currently have works fine on openSUSE, at least as far as I was able to test yet (except first boot detection, as we do not touch that file, didn't looked at that yet and will not before december). The only part where I think distros will differ would be bootloader support for first boot. I think the common part with distribution specific overrides should work.

…

-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)

[dustymabe]

@ajeddeloh
I think if we can unify *COS and CL then we have a shot, but otherwise I'm pretty pessimistic

I agree that would be a good test, but the risk to CL might be high. Would a valid other test with low risk of breaking things (because nothing depends on this yet as no prod workloads are on it) be for fedora coreos, RH coreos, and Suse to share the repo?

[dustymabe]

discussed in today's meeting. Will progress with moving this repo to https://github.com/coreos/ignition-dracut.

[dustymabe]

Migrated. Repo now at: https://github.com/coreos/ignition-dracut