Comment 2 for bug 1817368

Well, the way I see, based on investigation and input from others at SUSE we have 2 options. We can set the default file name for the netrules_path to something safe (80-pesistent-netrules-cloud-init.rules) for example. That would avoid the issue, the cloud-init generated rules would be last and thus the user supplied network setup would be applied. If we choose this path then IMHO netrules_path should no longer be configurable.

If we stay with the current intend, i.e. netrules_path is configurable then we want the updates in MP.

I have no strong opinion either way.

The image used that created this problem does have persistent names and systemd, yes. It also has a "large" number of network interfaces.

The way the systemd dependencies are setup today cloud-init-local.service and systemd-udevd.service can run at the same time and both write to 70-persistent-net.rules so there will always be a race. The third option is the cloud-init-local.service gets an

"After=systemd-udevd.service"

but I am not certain that will not create a cycle as cloud-init-local.service also has a

"Before=network-pre.target"

If we can avoid cycles, then the best solution, IMHO, is the change in order in cloud-init-local.service.