Coder Social home page Coder Social logo

Comments (19)

lucab avatar lucab commented on July 18, 2024

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

from fedora-coreos-tracker.

dustymabe avatar dustymabe commented on July 18, 2024

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?

from fedora-coreos-tracker.

ajeddeloh avatar ajeddeloh commented on July 18, 2024

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.

from fedora-coreos-tracker.

cgwalters avatar cgwalters commented on July 18, 2024

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

from fedora-coreos-tracker.

dustymabe avatar dustymabe commented on July 18, 2024

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?

from fedora-coreos-tracker.

ajeddeloh avatar ajeddeloh commented on July 18, 2024

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?

from fedora-coreos-tracker.

lucab avatar lucab commented on July 18, 2024

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.

from fedora-coreos-tracker.

ajeddeloh avatar ajeddeloh commented on July 18, 2024

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

from fedora-coreos-tracker.

cgwalters avatar cgwalters commented on July 18, 2024

fcos-dracut-modules seems sane to me.

from fedora-coreos-tracker.

dustymabe avatar dustymabe commented on July 18, 2024

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.

from fedora-coreos-tracker.

dustymabe avatar dustymabe commented on July 18, 2024

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.

from fedora-coreos-tracker.

dustymabe avatar dustymabe commented on July 18, 2024

cc @lucab @ajeddeloh since you had discussion input above

from fedora-coreos-tracker.

ajeddeloh avatar ajeddeloh commented on July 18, 2024

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.

from fedora-coreos-tracker.

dustymabe avatar dustymabe commented on July 18, 2024

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.

from fedora-coreos-tracker.

ajeddeloh avatar ajeddeloh commented on July 18, 2024

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.

from fedora-coreos-tracker.

thkukuk avatar thkukuk commented on July 18, 2024

from fedora-coreos-tracker.

dustymabe avatar dustymabe commented on July 18, 2024

@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?

from fedora-coreos-tracker.

dustymabe avatar dustymabe commented on July 18, 2024

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

from fedora-coreos-tracker.

dustymabe avatar dustymabe commented on July 18, 2024

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

from fedora-coreos-tracker.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.