-
Notifications
You must be signed in to change notification settings - Fork 223
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
…/configure Run using: LD_LIBRARY_PATH=_build/src NETPLAN_DBUS_CMD=_build/dbus/netplan-dbus NETPLAN_GENERATE_PATH=$(pwd)/_build/src/generate G_DEBUG=fatal_criticals PYTHONPATH=_build/python-cffi:. pytest -s -v tests/generator/test_sd-generator.py
…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.
6b93b00
to
49cfdcd
Compare
Description
Refactor Netplan's
generate
binary 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
..service
units oroverride.conf
drop-in configs) is now generated insrc/gen-*.c
and run duringdaemon-reload
.src/{networkd,nm,sriov,openvswitch}.c
.TestSystemdGenerator.test_sandbox
), that make sure theusr/libexec/netplan/generate
binary does not write files outside the allowed scope for a systemd-generator.--networkmanager-only
parameter, 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 check
successfully.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-only
flag.