Skip to content
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

compose: Initial kickstart support #5119

Merged
merged 1 commit into from
Oct 11, 2024
Merged

Conversation

cgwalters
Copy link
Member

The treefile syntax is...ok, but it is bespoke to us and we never really emphasized its use outside of our sphere.

As I'm looking at https://gitlab.com/fedora/bootc/tracker/-/issues/32 I'd really like to expose something that has existing widespread use as a default entrypoint.

kickstart is really old, long predating even virtualization.

It has a decent set of features (includes, comments) as a baseline specifically as a mechanism to define package sets, it has key features we want:

  • turning off weak dependencies
  • excludes

This is just a stub kickstart parser...the next step is to wire this up into the treefile.

Copy link

openshift-ci bot commented Oct 4, 2024

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@cgwalters cgwalters force-pushed the pkg-kickstart branch 2 times, most recently from 27ed0ac to ef040e1 Compare October 7, 2024 18:04
@cgwalters cgwalters marked this pull request as ready for review October 7, 2024 18:04
@cgwalters
Copy link
Member Author

OK, moving this one out of draft...I think it works enough to demonstrate the idea.

Opinions?

The treefile syntax is...ok, but it is bespoke to us and
we never really emphasized its use outside of our sphere.

As I'm looking at https://gitlab.com/fedora/bootc/tracker/-/issues/32
I'd really like to expose something that has existing widespread
use as a default entrypoint.

kickstart is really old, long predating even virtualization.

It has a decent set of features (includes, comments) as a baseline
specifically as a mechanism to define package sets, it has key
features we want:

- turning off weak dependencies
- excludes

This is just a stub kickstart parser...the next step is to
wire this up into the treefile.

Signed-off-by: Colin Walters <walters@verbum.org>
@jmarrero
Copy link
Member

jmarrero commented Oct 8, 2024

this looks ok to me, I personally would love if we could move people to the treefile instead of us adopting kickstart. For me yaml is so much nicer and feels modern vs kickstarts but I understand that ks is understood and wildly used in the RH/CentOS/Fedora universe and might be what people expect to use to build their images.

Copy link
Member

@jmarrero jmarrero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@jmarrero jmarrero merged commit b8667b9 into coreos:main Oct 11, 2024
17 checks passed
@jmpolom
Copy link

jmpolom commented Oct 15, 2024

This was already merged however from a user who has fought with both kickstart (in anaconda) and the treefile format, I'm concerned how this improves the experience of building custom ostree images. I'm also concerned about the introduction of a new parser within bootc to handle the ks format. Seems like this should be modularized out into a separate crate which can independently developed, tested and validated. The support is so barebones (vs what kickstart supports in anaconda and vs what treefile supports) I question what benefits this will have for those of us composing custom images.

Edit: to be more helpful with my feedback, supporting pre and post scripts is probably an essential feature for this to be even minimally viable for most use cases I can think of. A downside of kickstart is I don't think it has a way to direct inclusion of a specific file into the resulting installation root fs. I do think whatever format is used to define ostree images should have a very easy way to drop in files into the resulting ostree root fs from within a directory structure that exists alongside the configuration information (kickstart/treefile whatever). Treefile does this today with add-files but it only will pull in files at the same level as the treefile which makes it obnoxious to use.

@cgwalters
Copy link
Member Author

Hi @jmpolom, thanks for your feedback. The target for this is just the package configuration.

. I'm also concerned about the introduction of a new parser within bootc

This project is rpm-ostree, not bootc. The bootc project is agnostic to the input build system.

to handle the ks format. Seems like this should be modularized out into a separate crate which can independently developed, tested and validated.

Yep definitely.

Edit: to be more helpful with my feedback, supporting pre and post scripts is probably an essential feature for this to be even minimally viable for most use cases I can think of.

In practice the goal of this is just to be a declarative package input; we wouldn't require all executable code to be done via kickstart.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants