Comments (19)
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.
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.
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.
Calling it bootengine-fcos
or something seems fine to me, not even sure we'd need a downstream branch.
from fedora-coreos-tracker.
so there are three sources:
- fedora provided (common) dracut modules/initramfs config
- ignition dracut modules
- 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.
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.
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.
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.
fcos-dracut-modules
seems sane to me.
from fedora-coreos-tracker.
so it seems like the concensus is to basically have two sources of dracut modules:
- fedora provided (common) dracut modules/initramfs config
- other FCOS needed modules/config (including ignition) in a
coreos-dracut-modules
package (i switched it fromfcos-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.
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.
cc @lucab @ajeddeloh since you had discussion input above
from fedora-coreos-tracker.
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.
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.
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.
from fedora-coreos-tracker.
@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.
discussed in today's meeting. Will progress with moving this repo to https://github.com/coreos/ignition-dracut.
from fedora-coreos-tracker.
Migrated. Repo now at: https://github.com/coreos/ignition-dracut
from fedora-coreos-tracker.
Related Issues (20)
- F40 FCOS Test Week on April 1 HOT 15
- F40 FCOS Test Day TODO List
- Ship dnf in FCOS and RHCOS HOT 15
- Ephemeral rootfs sizing in live environment doesn't account for swap space HOT 3
- Add extra testing for kdump
- New Package Request: zip HOT 12
- Txn FinalizeDeployment on /org/projectatomic/rpmostree1/fedora_coreos failed: Staged deployment already unlocked HOT 11
- [rawhide] kdump.crash fails missing makedumpfile HOT 3
- [rawhide] kernel 6.9 regressions causing podman test failures HOT 2
- shim-x64-15.8-2 update causes secureboot test failures HOT 23
- tracker: Rebase onto Fedora 41
- Join the Special Purpose Operating System Working Group (CNCF) HOT 2
- Installation of packages fails in RPi 4 ignition HOT 2
- [rawhide][ppc64le] ext.config.kdump.crash failure HOT 7
- Update all repos to peter-evans/[email protected] HOT 8
- tracker: package additions/removals for F40 HOT 11
- Platform Request: Akamai Connected Cloud (Linode) HOT 5
- google-compute-engine-guest-configs-udev has been retired in Fedora HOT 3
- SELinux causes layered buildah network namespace failures HOT 14
- podman outgoing http connections are broken HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fedora-coreos-tracker.