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 succeeded. 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. Regards Nisha On Thu, Nov 26, 2020 at 6:51 AM Ian Wienand <iwienand@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@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@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@enp1s0 should be running before it.
The glean@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@.ser... [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.