-
Notifications
You must be signed in to change notification settings - Fork 50
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
Add support for arbitrary kickstart file injection into ISOs (HMS-3879) #631
Conversation
a94dd59
to
04dae33
Compare
This will need to be rebased once #632 is merged. |
04dae33
to
31cf582
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1acd9bd
to
1684b8f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not do a super deep review (too many distractions) but I read through and it looks very nice. I especially like that the kickstart options are now all consolidated, very nice work!
I wonder if we should run |
That would be a good idea yes; we currently only do so in testcases. |
1684b8f
to
d30ec72
Compare
d30ec72
to
49371fb
Compare
Could be a good idea, yeah. Though, it gets tricky with cross-distro builds doesn't it? If you're building a RHEL N image on RHEL N+1, you'd want to run it through the validator for RHEL N, not the newer one. So it should probably happen in the buildroot in osbuild I guess? |
49371fb
to
c44037b
Compare
As long as it knows the release name that pykickstart recoginizes (RHEL9, RHEL10, etc.) and is running on the same or newer release it will work. No need to try and work this into this PR though, it can come later. |
c0578d6
to
b4a7ad7
Compare
After discussing with @ondrejbudai and @mvo5, we decided that user kickstarts combined with any other kickstart customization would not be supported and produce errors. So now, if a user adds a kickstart file/contents, we only add the install line for the payload and then have the user's kickstart file include ours. For that last part, it would be nicer if our kickstart had an |
The test config file,
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! I really like the new kickstart.Options struct, this makes a lot of things cleaner. I added some ideas inline, I hope they are useful. But no blockers, so could be followups of course.
Do not allow or add any kickstart options to the bootc container installer ISO when a user kickstart is included. The only line that we add is the ostree container installation line in its own kickstart. The user kickstart file is then added separately and it %includes our own.
Do not allow or add any kickstart options to the tar payload installer (image-installer) or the ostree installer (edge/iot-installer). The only line that we add is the installation line in its own kickstart. The user kickstart file is then added separately and it %includes our own.
1. Kickstart tests now check if the pipeline serialization panic()s when unsupported options are combined. 2. When "extra" kickstart content is defined (user kickstart file), the pre-defined hardcoded kickstart bits aren't added to the checksum calculation.
Unattended + kickstart.contents is no longer allowed, so set unattended to false.
b4a7ad7
to
8e9efc4
Compare
Initialise kickstart customizations for an image with the common options from the blueprint customizations. The kickstart options are initialised with Users, Groups, the Unattended and SudoNopasswd installer options, and the custom kickstart content. Other options (Language, Keyboard, Timezone, and payload options) must be set separately, since they aren't based solely on the blueprint customizations and interact with other configs, like image config or the ostree payload options. Co-authored-by: Michael Vogt <michael.vogt@gmail.com>
Co-authored-by: Michael Vogt <michael.vogt@gmail.com>
Validate kickstart options in a Validate() function so unify option compatibility handling. The function is called from the kickstart.New() initialiser, but we also call it before stage creation to make sure everything is valid right before stage creation. Co-authored-by: Michael Vogt <michael.vogt@gmail.com>
8e9efc4
to
df3bdb4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some quick drive by comments but I like it and nothing blocks it, really just optimizing :)
@mvo5 @noelmiller I created issues with your comments to look into later (#691, #692). The PR is already long enough and does the basics. We can polish the code in separate PRs (for Michael's comments). We need to have a discussion about the mechanics of Anaconda Kickstart modules (for Noel's comments) and I think that might block this for too long and make the PR even harder to review. I propose we merge this as is unless there are other blockers. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! This looks great, I had ideas in the previous comment but they should not be blockers, could be a followup as well (or ignored if I missed something there of course :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still looking good! Sorry, I accidentally pushed to this branch but fixed it right away.
Update to accomodate for the changes in the API that got introduced in osbuild/images#631 (ideally that PR would have been split into a part that changes the API and one that adds the new feature. This would have made it slightly easier to see the API changes in isolation).
Update to accomodate for the changes in the API that got introduced in osbuild/images#631 (ideally that PR would have been split into a part that changes the API and one that adds the new feature. This would have made it slightly easier to see the API changes in isolation).
I also had to adjust our use of AnacondaContainerInstaller because it was changed in osbuild/images#631.
I also had to adjust our use of AnacondaContainerInstaller because it was changed in osbuild/images#631.
Adds a new blueprint customization
[installer.kickstart.contents]
that will allow users to inject their own kickstart file into an ISO build.This PR also includes a partial implementation of a recommendation I made in a previous PR: #614 (comment)
A new internal customization struct called
kickstart.Options
holds all kickstart options that we can set in pipelines and is attached to Anaconda pipelines and image kinds that support them. This is similar to other internal options structs like users.User, users.Group, fsnode.File, etc.There's a bit more we can do with this (for example a
ks.GetPath()
method that returns the default when it's not set, even withks == nil
, instead of checking all the time) but I wanted to get this PR open and merged to get this into bootc-image-builder.Note that our initial idea was to make any other kickstart option illegal when this option is used. Leaving it wide open can cause all sorts of issues for users who don't know what we're adding to the kickstart when they append their own, but from what I understand, it should be safe in the general case where they add some
%post
bits or enable options we don't support.I'm fine with restricting it if others disagree.