DLPX-79416 [Backport of DLPX-79034 to 6.0.13.0] systemd-networkd releases its DHCP lease on restart

[sebroy]

Clean cherry-pick of #358

ab-pre-push: http://selfservice.jenkins.delphix.com/job/appliance-build-orchestrator-pre-push/707/

[prakashsurya]

I'm not familiar with this file scheme, but presumably you verified this to work, so LGTM.

[sebroy]

Yes, I provided the testing details in the original jira issue. We no longer see the symptoms reported in TOOL-12800, and I verified that the lease doesn't get released when restarting the service:

Feb 02 21:02:53 ip-10-110-208-129 systemd[1]: Stopping Network Service...
Feb 02 21:02:53 ip-10-110-208-129 systemd-networkd[29312]: Restart operation initiated.
Feb 02 21:02:53 ip-10-110-208-129 systemd-networkd[29312]: Bus bus-api-network: changing state RUNNING → CLOSED
Feb 02 21:02:53 ip-10-110-208-129 systemd-networkd[29312]: DHCP CLIENT (0x21cfa783): FREE
Feb 02 21:02:53 ip-10-110-208-129 systemd[1]: systemd-networkd.service: Succeeded.
Feb 02 21:02:53 ip-10-110-208-129 systemd[1]: Stopped Network Service.

Regarding the file scheme, here are the relevant part of the systemd.network(5) man page:

       The .network files are read from the files located in the system network directories /lib/systemd/network and
       /usr/local/lib/systemd/network, the volatile runtime network directory /run/systemd/network and the local
       administration network directory /etc/systemd/network. All configuration files are collectively sorted and
       processed in lexical order, regardless of the directories in which they live. However, files with identical
       filenames replace each other. Files in /etc have the highest priority, files in /run take precedence over
       files with the same name under /usr. This can be used to override a system-supplied configuration file with a
       local file if needed. As a special case, an empty file (file size 0) or symlink with the same name pointing to
       /dev/null disables the configuration file entirely (it is "masked").

       Along with the network file foo.network, a "drop-in" directory foo.network.d/ may exist. All files with the
       suffix ".conf" from this directory will be parsed after the file itself is parsed. This is useful to alter or
       add configuration settings, without having to modify the main configuration file. Each drop-in file must have
       appropriate section headers.

       In addition to /etc/systemd/network, drop-in ".d" directories can be placed in /lib/systemd/network or
       /run/systemd/network directories. Drop-in files in /etc take precedence over those in /run which in turn take
       precedence over those in /lib. Drop-in files under any of these directories take precedence over the main
       network file wherever located.

And:

       The network file contains a "[Match]" section, which determines if a given network file may be applied to a
       given device; and a "[Network]" section specifying how the device should be configured. The first (in lexical
       order) of the network files that matches a given device is applied, all later files are ignored, even if they
       match as well.

       A network file is said to match a network interface if all matches specified by the "[Match]" section are
       satisfied. When a network file does not contain valid settings in "[Match]" section, then the file will match
       all interfaces and systemd-networkd warns about that. Hint: to avoid the warning and to make it clear that all
       interfaces shall be matched, add the following:

           Name=*

[prakashsurya]

Awesome, thanks @sebroy!

[sebroy]

I'm discarding this review, will revert the commit on master, and will replace the fix with http://reviews.delphix.com/r/78103/. The original fix I had here did not work, as the files generated by netplan apply in /run/systemd/network/... override the configuration everytime. The solution is to implement this fix in our netplan yaml itself.