-
Notifications
You must be signed in to change notification settings - Fork 226
Split generate/configure stages for sd-generator compliance #552
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
base: main
Are you sure you want to change the base?
Conversation
8287a28 to
9105838
Compare
15db9ad to
320629c
Compare
Packaging TODOs
|
320629c to
4f36a61
Compare
b507c0d to
d2bd8a8
Compare
869fc6e to
1ee0b9f
Compare
42d4420 to
14a12f9
Compare
14a12f9 to
c1cd723
Compare
1fbbcc2 to
5c7c78c
Compare
|
rebased to resolve conflicts against #563 |
…rator and network-configurator This is to make them fail under the same circumstances, e.g. do not generate systemd units corresponding to network interfaces that we cannot write any network configuration files for, due to some late-stage validation error. Adding new (internal, for now) _netplan_state_get/set_flags() API. This is enabled by passing a new NETPLAN_STATE_VALIDATION_ONLY flag to NetplanState, to skip writing out files. - The sd-generator (./generate) should not write any network configuration, but still needs to run through its late-stage validations, to fail if the network-configuration would fail. - The network-configuration should not write any systemd units, but still needs to run trhough its late-stage validations, in order to fail if the sd-generator would fail. Future improvement: Ideally, there should not be any late-stage validation inside file writing logic (e.g. [gen-]networkd.c, [gen-]openvswitch.c, ...), but all validation should already be done in the central validation.c stage. Unfortunately, such change is out of scope for this PR.
…r integration during 'netplan try'
…#2090848) This avoids conflicts with AppArmor confinement when re-generating the network configuration from within NetworkManager.
See original PR: canonical#162
It introduces unrelated failures and wastes resources, as we're not currently affected by an ABI breaking change.
…nerator This was originally implemented to generate & start systemd units just-in-time during the boot transaction (canonical#162). With the implementation of a proper systemd-generator, Netplan generates the corresponding units in /run/system/generator* and automatically re-loads and re-calculates dependencies during "daemon-reload". Therefore, we do not need to inject them manually. This is covered by the "cloud-init" autopkgtest.
sbuild does not provide a fully functional systemd environment, as indicated by the existance of /run/systemd/system. Therefore, we cannot rely on the systemd-run sandbox in such environments.
5c7c78c to
b05807e
Compare
Description
Refactor Netplan's
generatebinary to be a proper systemd.generator, according to spec "FO165 – Netplan generator architecture".New testing of a simulated systemd sandbox is implemented in
tests/generator/test_sd-generator.py..serviceunits oroverride.confdrop-in configs) is now generated insrc/gen-*.cand run duringdaemon-reload.src/{networkd,nm,sriov,openvswitch}.c.TestSystemdGenerator.test_sandbox), that make sure theusr/libexec/netplan/generatebinary does not write files outside the allowed scope for a systemd-generator.--networkmanager-onlyparameter, to improve NM integration, by not touching any systemd[-networkd] files_netplan_state_get/set_flags()API (internal, for now) to do "validation-only" runs over our NetDef dataChecklist
make checksuccessfully.make check-coverage).This should also fix https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2083129 by not re-generating NM configuration on the fly. And https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2090848 by using the new
/usr/libexec/netplan/configure --networkmanager-onlyflag.