Add network flushing before setting up network

[sergio-correia]

This should allow for using the nbde_client role with machines that use
static IP configurations, as network flushing should undo the network
setup done at the initramfs, allowing the system to use its regular
configuration.

Approach based on the answers posted here:
https://unix.stackexchange.com/questions/506331/networkmanager-doesnt-change-ip-address-when-dracut-cmdline-provided-static-ip/541108

[richm]

@tyll is there a better way to do this?

[tyll]

you mean to get a list of all interfaces?

ip -oneline link show can make the sed expression easier or you can use cut and remove the leading whitespace. There is also -brief so ip -oneline -brief link show | cut -d" " -f 1 can be an option, too. Technically, interface names can use any encoding and character, so this is all not 100% correct. ip -json -brief can create json output that might handle this best but would need a more complex script to handle it.

Each interface is also a symlink in /sys/class/net/, so you can also get the interface names like this:

for f in /sys/class/net/*; do echo ${f##*/}; done

@thom311 any suggestions/comments?

[thom311]

JSON output of iproute2 would be nicer. But on some systems, that's not available (in particular, CentOS7).

From sysfs might be good. Note there are some special files there like bonding_masters. Guess you could do something like (cd /sys/class/net/; for f in */; do echo ${f%/}; done) to get rid of that.

but I have no strong preference here.

Sergio, did you strip interfaces with a parent, like vethf6a43f04@if9, on purpose?

[sergio-correia]

Sergio, did you strip interfaces with a parent, like vethf6a43f04@if9, on purpose?

It was probably accidental. I initially was using nmcli -t device, which was simpler to use the output with cut, but I think I had issues with CentOS 7, then I switched to this other approach. I like your suggestion (and tyll's) of using /sys/class/net/, so I will change to use it instead. Thanks!

[richm]

[citest bad]

[richm]

@sergio-correia how do we test this? Can we have an automated test for this?

[richm]

[citest bad]

[sergio-correia]

@sergio-correia how do we test this? Can we have an automated test for this?

One way to to test this would be to configure a system set up with a LUKS-encrypted device and a static IP address. We can then use the ansible role and once the machine does the automated unlocked, after a reboot, we can inspect that it still has the same static IP that it was configured before.

it's not impossible to have an automated test for this, but it's not straightforward either. We could easily provision a VM with the required setup with a kickstart file, for instance, but then we need a way to make sure the VM boots properly the first time, without user interaction.

[richm]

@sergio-correia how do we test this? Can we have an automated test for this?

One way to to test this would be to configure a system set up with a LUKS-encrypted device and a static IP address. We can then use the ansible role and once the machine does the automated unlocked, after a reboot, we can inspect that it still has the same static IP that it was configured before.

Do we need a separate nbde server machine to test this? If so, then we can't have an automated test for this, at least with our current test framework. Then assuming we can't have an automated test for this, what is the QE procedure to verify this change?

it's not impossible to have an automated test for this, but it's not straightforward either. We could easily provision a VM with the required setup with a kickstart file, for instance, but then we need a way to make sure the VM boots properly the first time, without user interaction.

[sergio-correia]

Do we need a separate nbde server machine to test this? If so, then we can't have an automated test for this, at least with our current test framework. Then assuming we can't have an automated test for this, what is the QE procedure to verify this change?

Yes, the nbde server machine cannot be the same one as the client, as the client will attempt to communicate with it while booting. If using virtualization, we could run the server on the host, whlie the guest would run the client.

As for the QE procedure to verify this, I am not 100% sure, but I suspect it would be a manual test doing what I suggested in the previous message: setting up a machine with LUKS and static IP and using the nbde_client role + a reboot to verify things worked as expected.

[richm]

lgtm - but first you will need to rebase on top of the latest master code - this changes the way the role is symlinked under tests/roles/linux-system-roles.nbde_client - you will need to add symlinks there for files and templates

[sergio-correia]

@richm: I have rebased it and added the symlinks.

[richm]

@richm: I have rebased it and added the symlinks.

Thanks! I'm monitoring the test runs - if they look good I'll merge

[richm]

[citest]

[sergio-correia]

@richm: what is the 2.9 version we use in those CentOS-7-latest/ansible-2.9/(citool) and RHEL-7.9-20200917.0/ansible-2.9/(citool) tests that failed?

[richm]

@richm: what is the 2.9 version we use in those CentOS-7-latest/ansible-2.9/(citool) and RHEL-7.9-20200917.0/ansible-2.9/(citool) tests that failed?

Don't worry about those failures - they are unrelated - the CI team is working on it.