[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