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.

Sign up for GitHub

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

Jump to bottom

30ignition-coreos: Add coreos-boot-edit.{service,sh} #743

Merged
merged 2 commits into from
Nov 23, 2020
Merged

30ignition-coreos: Add coreos-boot-edit.{service,sh} #743

merged 2 commits into from
Nov 23, 2020

Conversation

kelvinfan001
Copy link
Member

@kelvinfan001 kelvinfan001 commented Nov 19, 2020 •
edited
Loading

coreos-boot-edit.service will run late in the initrd process after
Ignition is completed successfully and temporarily mount /boot read write
to make edits (e.g. removing firstboot networking configuration
files if necessary).

We would like to mount /boot read-only in the real root,
so remove the current 15-coreos-firstboot-network.conf since
it would not work once /boot is mounted ro. Drop a stamp
file instead so that coreos-boot-edit.service would notice
and perform the clean up later in the initramfs.

xref #659

@kelvinfan001 kelvinfan001 added the WIP PR still being worked on label Nov 19, 2020
@kelvinfan001 kelvinfan001 force-pushed the kfan-cleanup-firstboot-network branch from 9b682d8 to 416b77c Compare November 19, 2020 17:20
@kelvinfan001 kelvinfan001 removed the WIP PR still being worked on label Nov 19, 2020
@kelvinfan001 kelvinfan001 changed the title [WIP] 15coreos-network: Add new unit to remove firstboot networking config 15coreos-network: Add new unit to remove firstboot networking config Nov 19, 2020
@kelvinfan001 kelvinfan001 requested a review from jlebon November 19, 2020 17:21
@dustymabe
Copy link
Member

dustymabe commented Nov 19, 2020 •
edited
Loading

hmm. I wonder if we could just do something similar to what coreos-teardown-initramfs.service is doing..

https://github.com/coreos/fedora-coreos-config/blob/599311b477f62b999bc923519f1920e04787ef09/overlay.d/05core/usr/lib/dracut/modules.d/30ignition-coreos/coreos-teardown-initramfs.service

i.e. there was a lot of logic put in there to make sure we ran after Ignition was complete, we may want to re-use some of it.

@kelvinfan001
Copy link
Member Author

hmm. I wonder if we could just do something similar to what coreos-teardown-initramfs.service is doing..

https://github.com/coreos/fedora-coreos-config/blob/599311b477f62b999bc923519f1920e04787ef09/overlay.d/05core/usr/lib/dracut/modules.d/30ignition-coreos/coreos-teardown-initramfs.service

i.e. there was a lot of logic put in there to make sure we ran after Ignition was complete, we may want to re-use some of it.

@dustymabe sorry I didn't really follow. Did you mean that the current After=ignition-files.service is insufficient to ensure that Ignition was complete?

@dustymabe
Copy link
Member

hmm. I wonder if we could just do something similar to what coreos-teardown-initramfs.service is doing..
https://github.com/coreos/fedora-coreos-config/blob/599311b477f62b999bc923519f1920e04787ef09/overlay.d/05core/usr/lib/dracut/modules.d/30ignition-coreos/coreos-teardown-initramfs.service
i.e. there was a lot of logic put in there to make sure we ran after Ignition was complete, we may want to re-use some of it.

@dustymabe sorry I didn't really follow. Did you mean that the current After=ignition-files.service is insufficient to ensure that Ignition was complete?

It should be fine, but to me it would be nice to only clean up these files once all stages of Ignition have run. Maybe After=ignition-files.service is good enough. @jlebon knows way more about this than I do, so I'll trust it if he's good with what you've proposed.

@kelvinfan001
Copy link
Member Author

ah got it. I guess it wouldn't hurt to be safer?

@jlebon
Copy link
Member

jlebon commented Nov 19, 2020

It should be fine, but to me it would be nice to only clean up these files once all stages of Ignition have run. Maybe After=ignition-files.service is good enough.

Meh, I'm fine either way really. Like I mentioned in IRC, I think a fundamental difference here from the network teardown one (and the umount stage) is that we want code which require these services not to have to think about their shutdown (and e.g. it's useful to have network/mounts still up in rd.break). I don't think the same argument applies here so personally I'd just keep it simple.

@kelvinfan001
coreos-copy-firstboot-network.sh: Place stamp file if copied
9df08be 
We would like to mount `/boot` read-only in the real root,
so remove the current 15-coreos-firstboot-network.conf since
it would not work once `/boot` is mounted ro. Drop a stamp
file instead so that `coreos-boot-edit.service` would notice
and perform the clean up later in the initramfs.

xref coreos#659
@kelvinfan001 kelvinfan001 force-pushed the kfan-cleanup-firstboot-network branch from 416b77c to 7e684bf Compare November 19, 2020 22:55
@kelvinfan001 kelvinfan001 changed the title 15coreos-network: Add new unit to remove firstboot networking config 30ignition-coreos: Add coreos-boot-edit.{service,sh} Nov 20, 2020
@kelvinfan001
30ignition-coreos: Add coreos-boot-edit.{service,sh}
4e38b36 
`coreos-boot-edit.service` will run late in the initrd process after
Ignition is completed successfully and temporarily mount /boot read-write
to make edits in (e.g. removing firstboot networking configuration
files if necessary).
@kelvinfan001 kelvinfan001 force-pushed the kfan-cleanup-firstboot-network branch from 7e684bf to 4e38b36 Compare November 20, 2020 16:50
jlebon
jlebon approved these changes Nov 23, 2020
View reviewed changes
Copy link
Member

@jlebon jlebon left a comment

Choose a reason for hiding this comment

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

LGTM!

overlay.d/05core/usr/lib/dracut/modules.d/30ignition-coreos/module-setup.sh
@@ -36,4 +36,11 @@ install() {
# units only started when we have a boot disk
# path generated by systemd-escape --path /dev/disk/by-label/root
install_ignition_unit coreos-gpt-setup.service ignition-diskful.target

inst_script "$moddir/coreos-boot-edit.sh" \
"/usr/sbin/coreos-boot-edit"
Copy link
Member

Choose a reason for hiding this comment

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

Hmm, this should probably be /usr/libexec instead, but not worth a respin! :)

travier
travier reviewed Nov 23, 2020
View reviewed changes
Copy link
Member

@travier travier left a comment

Choose a reason for hiding this comment

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

LGTM overall but is there any specific reason to not directly always remove the files? I don't think we need to be extra careful here.

overlay.d/05core/usr/lib/dracut/modules.d/30ignition-coreos/coreos-boot-edit.service
Comment on lines +11 to +13
# Since we are mounting /boot, require the device first
Requires=dev-disk-by\x2dlabel-boot.device
After=dev-disk-by\x2dlabel-boot.device
Copy link
Member

Choose a reason for hiding this comment

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

I don't think that's needed with After=ignition-files.service. But this probably does not hurt either.

@kelvinfan001
Copy link
Member Author

@travier I think you're right. The stamp file seems a bit unnecessary now. It was originally there because we could potentially not run the service that removes those files if there are no files to clean up in /boot. But then we decided to merge the firstboot network config clean up service into a single coreos-boot-edit.service that will be in charge of doing all the stuff we want to do to /boot after Ignition and probably needs to be run every time.
Anyways, going to merge for now. The extra carefulness shouldn't hurt, right?

@kelvinfan001 kelvinfan001 merged commit 993697e into coreos:testing-devel Nov 23, 2020
@kelvinfan001 kelvinfan001 deleted the kfan-cleanup-firstboot-network branch November 23, 2020 15:55
@travier
Copy link
Member

travier commented Nov 23, 2020

The extra carefulness shouldn't hurt, right?

Unnecessary complexity may lead to issues but things here looks fine. We will revisit later if needed.

jlebon added a commit to jlebon/fedora-coreos-config that referenced this pull request Nov 23, 2020
@jlebon
coreos-boot-edit: add triggering condition on coreos-copy-firstboot-n…
1ba7e94 
…etwork.stamp

That way we completely avoid mounting `/boot` rw if we don't need to.
Also clarify comment about the boot dependency. Additional roles for
this service ideally would follow the same pattern.

Minor follow-up to coreos#743.
@jlebon jlebon mentioned this pull request Nov 23, 2020
Closed
@jlebon
Copy link
Member

jlebon commented Nov 23, 2020

I think the stamp file is useful so that we can make this whole unit conditional: #745.

@kelvinfan001 kelvinfan001 mentioned this pull request Dec 4, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@travier travier travier left review comments

@dustymabe dustymabe dustymabe left review comments

@jlebon jlebon jlebon approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@kelvinfan001 @dustymabe @jlebon @travier