Open Stack

Hi,

Thank you for your input!

On Wed, Nov 25, 2020 at 3:09 AM Ian Wienand <iwienand at redhat.com> wrote:

> On Tue, Nov 24, 2020 at 11:54:55AM +0100, Dmitry Tantsur wrote:
> > The problem is, I cannot make Glean work with any ramdisk I build. The
> crux
> > of the problem seems to be that NetworkManager (used by default in RHEL,
> > CentOS, Fedora and Debian at least) starts very early, creates the
> default
> > connection and ignores whatever files Glean happens to write afterwards.
> On
> > Debian running `systemctl restart networking` actually helped to pick the
> > new configuration, but I'm not sure we want to do that in Glean. I
> haven't
> > been able to make NetworkManager pick up the changes on RH systems so
> far.
>
> So we do use NetworkManager in the OpenDev images, and we do not see
> NetworkManager starting before glean.
>

Okay, thanks for confirming. Maybe it's related to how IPA is built? It's
not exactly a normal image after all, although it's pretty close to one.


>
> The way it should work is that simple-init in dib installs glean to
> the image.  That runs the glean install script (use --use-nm argument
> if DIB_SIMPLE_INIT_NETWORKMANAGER, which is default on centos/fedora)
> which installs two things; udev rules and a systemd handler.
>

I have checked that these are installed, but I don't know how to verify a
udev rule.


>
> The udev is pretty simple [1] and should add a "Wants" for each net
> device; e.g. eth1 would match and create a Wants glean at eth1.service,
> which then matches [2] which should write out the ifcfg config file.
> After this, NetworkManager should start, notice the config file for
> the interface and bring it up.
>

Yeah, I definitely see logging from NetworkManager DHCP before this service
is run (i.e. before the output from Glean).


>
> > Do you maybe have any hints how to proceed? I'd be curious to know how
> > static IP assignment works in the infra setup. Do you have images with
> > NetworkManager there? Do you use the simple-init element?
>
> As noted yes we use this.  Really only in two contexts; it's Rackspace
> that doesn't have DHCP so we have to setup the interface statically
> from the configdrive data.  Other clouds all provide DHCP, which is
> used when there's no configdrive data.
>
> Here is a systemd-analyze from one of our Centos nodes if it helps:
>

> graphical.target @18.403s
> └─multi-user.target @18.403s
>   └─unbound.service @5.467s +12.934s
>     └─network.target @5.454s
>       └─NetworkManager.service @5.339s +112ms
>         └─network-pre.target @5.334s
>           └─glean at ens3.service @4.227s +1.102s
>             └─basic.target @4.167s
>               └─sockets.target @4.166s
>                 └─iscsiuio.socket @4.165s
>                   └─sysinit.target @4.153s
>                     └─systemd-udev-settle.service @1.905s +2.245s
>                       └─systemd-udev-trigger.service @1.242s +659ms
>                         └─systemd-udevd-control.socket @1.239s
>                           └─system.slice
>

# 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

# cat /etc/sysconfig/network-scripts/ifcfg-enp1s0
# Automatically generated, do not edit
DEVICE=enp1s0
BOOTPROTO=static
HWADDR=52:54:00:1f:79:7e
IPADDR=192.168.122.42
NETMASK=255.255.255.0
ONBOOT=yes
NM_CONTROLLED=yes

# ip addr
...
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state
UP group default qlen 1000
    link/ether 52:54:00:1f:79:7e brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.77/24 brd 192.168.122.255 scope global dynamic
noprefixroute enp1s0
       valid_lft 42957sec preferred_lft 42957sec
    inet6 fe80::f182:7fb4:7a39:eb7b/64 scope link noprefixroute
       valid_lft forever preferred_lft forever


> At a guess; I feel like the udev bits are probably not happening
> correctly in your case?  That's important to get the glean@<interface>
> service in the chain to pre-create the config file
>

It seems that the ordering is correct and the interface service is
executed, but the IP address is nonetheless wrong.

Can it be related to how long glean takes to run in my case (54 seconds vs
1 second in your case)?

Dmitry


>
> -i
>
> [1]
> https://opendev.org/opendev/glean/src/branch/master/glean/init/glean-udev.rules
> [2]
> https://opendev.org/opendev/glean/src/branch/master/glean/init/glean-nm@.service
>
>

-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
O'Neill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201125/003f87a5/attachment.html>