[ironic] [infra] Making Glean work with IPA for static IP assignment

Nisha Agarwal agarwalnisha1980 at gmail.com
Wed Jan 20 15:06:03 UTC 2021

Hi Ian,

We were trying the same thing and the deploy fails when we use CentOS8 or
Ubuntu ramdisk. Glean is able to modify the network scripts but looks like
Networking/NetworkManager is not restarted after that and ip is not
assigned to the interface. Manually I just did "systemctl
restart NetworkManager" on the CentOS8 system and after that the deploy

Is there a bug for this? and is there any plan to fix the issue ?
If there is no bug existing for the issue, I am planning to raise one.

The image is built using following command:
disk-image-create -o centos_deploy_image ironic-python-agent-ramdisk centos
simple-init devuser selinux-permissive

As a side note, the centos7 image created using above works fine for us and
the dhcpless deploy works end-to-end using ironic.


On Thu, Nov 26, 2020 at 6:51 AM Ian Wienand <iwienand at redhat.com> wrote:

> On Wed, Nov 25, 2020 at 11:54:13AM +0100, Dmitry Tantsur wrote:
> >
> > # systemd-analyze critical-chain
> > multi-user.target @2min 6.301s
> > └─tuned.service @1min 32.273s +34.024s
> >   └─network.target @1min 31.590s
> >     └─network-pre.target @1min 31.579s
> >       └─glean at enp1s0.service @36.594s +54.952s
> >         └─system-glean.slice @36.493s
> >           └─system.slice @4.083s
> >             └─-.slice @4.080s
> >
> > # systemd-analyze critical-chain NetworkManager.service
> > NetworkManager.service +9.287s
> > └─network-pre.target @1min 31.579s
> >   └─glean at enp1s0.service @36.594s +54.952s
> >     └─system-glean.slice @36.493s
> >       └─system.slice @4.083s
> >         └─-.slice @4.080s
> > It seems that the ordering is correct and the interface service is
> > executed, but the IP address is nonetheless wrong.
> I agree, this seems to say to me that NetworkManager should run after
> network.pre-target, and glean at enp1s0 should be running before it.
> The glean at enp1s0.service is set as oneshot [1] which should prevent
> network-pre.target being reached until it exits:
>  oneshot ... [the] service manager will consider the unit up after the
>  main process exits. It will then start follow-up units.
> To the best of my knowledge the dependencies are correct; but if you
> go through the "git log" of the project you can find some history of
> us thinking ordering was correct and finding issues.
> > Can it be related to how long glean takes to run in my case (54 seconds
> vs
> > 1 second in your case)?
> The glean script doesn't run asynchronously in any way (at least not
> on purpose!).  I can't see any way it could exit before the ifcfg file
> is written out.
> > # cat /etc/sysconfig/network-scripts/ifcfg-enp1s0
> ...
> The way NM support works is writing out this file which is read by the
> NM ifcfg-rh plugin [2].  AFAIK that's built-in to NM so would not be
> missing, and I think you'd have to go to effort to manually edit
> /etc/NetworkManager/conf.d/99-main-plugins.conf to have it ignored.
> I'm afraid that's overall not much help.  Are you sure there isn't an
> errant dhclient running somehow that grabs a different address?  Does
> it get the correct address on reboot; implying the ifcfg- file is read
> correctly but somehow isn't in place before NetworkManager starts?
> -i
> [1]
> https://opendev.org/opendev/glean/src/branch/master/glean/init/glean-nm@.service#L13
> [2]
> https://developer.gnome.org/NetworkManager/stable/nm-settings-ifcfg-rh.html

The Secret Of Success is learning how to use pain and pleasure, instead
of having pain and pleasure use you. If You do that you are in control
of your life. If you don't life controls you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210120/b8abf9bb/attachment.html>

More information about the openstack-discuss mailing list