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]

[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.