-
Notifications
You must be signed in to change notification settings - Fork 208
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
Create custom systemd-networkd-wait-online.service override to wait on individual interfaces. (LP: #2060311) #456
Merged
Merged
Changes from all commits
Commits
Show all changes
11 commits
Select commit
Hold shift + click to select a range
c436abd
util: fix potential NULL pointer assert
slyon a9d5383
networkd: add wait-online enumeration utils
slyon 3fe2f40
generate: enable systemd-networkd-wait-online for non-optional interf…
slyon c567a4b
CLI:utils: Do not ask for daemon-reload password interactively
slyon c0c6260
CLI:generate: call daemon-reload after (re-)generating services
slyon df8161a
wait-online: Do not block on loopback interface
slyon ef055db
generate: Do not touch wait-online, if we don't have any networkd Net…
slyon 7d5d50c
wait-online: wait for existing interfaces only and downgrade operatio…
slyon a4f803e
wait-online: account for DHCPv4/v6 addresses
slyon a00ec97
wait-online: do not require virtual devices to be created already
slyon 1cb2129
wait-online: recognize that bridge/bond members will never gain link-…
slyon File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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'm not certain here about the impact of ignoring devices not currently present in /sys/class/net during systemd generator timeframe. By only considering interfaces already present in /sys/class/net, are we exposed to scenarios where the device drivers for the specified device haven't loaded yet (in initramfs-less environments without the proper drivers compiled into the kernel)? This reminds me of this cloud-init issue canonical/cloud-init#4451 for minimal images. In the event that we don't have device drivers loaded (from initramfs or kernel static compiled), is it possible
netplan's generatornetplan generate
may not see the device in /sys/class/net viaif_nameindex
and systemd-networkd-wait-online will be disabled right? Maybe in this case, we prescribe that initramfs/kernel must have the desired device drivers in order to expect systemd-networkd-wait-online to block properly.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.
A similar (the same?) issue will happen with virtual devices. By the time the generator runs they will not be created yet so they will not be in the list.
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.
James corrected me, this isn't systemd generator timeframe, but the point in time when
netplan generate
is called. For cloud-init init-local boot stage, I think we may still be exposed to this race where cloud-init local gets in and invokesnetplan generate
possibly before supplemental device drivers have loaded. So this may still be a concern.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.
Oh! That's a very interesting case.. I just pushed more commits to not require virtual devices (bridges, bonds, dummys, ...) to be available in
/sys/class/net
just yet. Those will be created later.For physical devices that are not yet loaded, I don't know. I don't think there's anything that can be done as part of this PR and such interfaces might be ignored by
systemd-networkd-wait-online
.A longer-term solution might be splitting up Netplan into a sytemd-generator and a systemd-service (running
Before=network-pre.target
, similar tosystemd-network-generator.service
), which we are tracking as spec "FO165 - Netplan generator architecture".Do you think this should be a blocker?
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 think this retains the same gap/issue cloud-init and systemd-networkd-wait-online are already exposed to, so I don't think this needs to be fixed in this PR. The stance we've taken already Ubuntu minimal case was to recompile the kernel to include the module built-ins that are required to support virtio-net to ensure they are loaded in time for network generation and network-online for "initrdless" boots. It feels "ok" to state that if you have a critical device driver needed in early boot for your cloud image and you are booting without initrd, you would either need to statically compile the necessary device drivers into that kernel, or use initrd and provide any supplemental drivers needed earlier boot. This may just be something we take into consideration for future behavior though, and thinking of how to approach this type of concern later in F0165 probably makes the most sense at the moment.