[ironic] [infra] Making Glean work with IPA for static IP assignment
Ian Wienand
iwienand at redhat.com
Thu Mar 18 05:12:22 UTC 2021
On Wed, Mar 17, 2021 at 04:52:10PM +0100, Dmitry Tantsur wrote:
> [ 63.613821] NetworkManager[244]: <info> [1615995259.7778] NetworkManager (version 1.26.0-12.el8_3) is starting... (for the first time)
> [ 71.637264] systemd[1]: Starting Glean for interface enp1s0 with
> Any ideas?
That seems to say that the NetworkManager daemon is starting before
glean.sh.
My NetworkManager /usr/lib/systemd/system/NetworkManager.service has
[Unit]
Description=Network Manager
Documentation=man:NetworkManager(8)
Wants=network.target
After=network-pre.target dbus.service
Before=network.target network.service
The glean service
https://opendev.org/opendev/glean/src/branch/master/glean/init/glean@.service
has
[Unit]
Description=Glean for interface %I
DefaultDependencies=no
Before=network-pre.target
Wants=network-pre.target
...
[Service]
Type=oneshot
It feels like we're really doing out best to tell NetworkManager to
start after network-pre.target and glean to start before it.
The service is "oneshot", doesn't exit until it is finished, and has
no timeout, so I don't see how network-pre can become active before
glean at .service finishes?
Can you run with "debug" on the kernel command-line, to maybe see why
it chose to start NM? Can you dump "systemd-analyze" plot maybe? I
know we looked at the dependency chain previously and it seemed OK ...
As you've seen with
https://review.opendev.org/c/opendev/glean/+/781133
https://review.opendev.org/c/opendev/glean/+/781174
there are certainly ways we can optimise glean more. But I really
would have thought these would just slow down the boot, not cause
ordering issues...
-i
More information about the openstack-discuss
mailing list