[PATCH master] Add tests for network --device missing and --device=link

Radek Vykydal rvykydal at redhat.com
Thu Jun 4 10:47:50 UTC 2015


On 06/03/2015 08:39 PM, Chris Lumens wrote:
>> These are only for one one NIC available.
> If you need the ability to set up more than one NIC, we should be able
> to allow that by passing additional --network= options to virt-install.
> It shouldn't be much work to set that up - probably pretty similar to
> the disk stuff.  It just hasn't been needed yet, so I haven't done
> anything for it.

What I'd like to have to create some more tests is

- Option to require more network devices. I looked at virt-install 
briefly, and I wasn't able to see if/how it is possible via 
virt-install, I can see only qemu config of my VMs, but can it be set by 
virt-install or by xml config only... I don't know.

- Possibility to refer to devices in the test
   - it can be either by MAC which should be configurable by mac option?
   - or we can assume ethX if virtio driver is used (model=virtio 
virt-install option)
   - or is there any way to learn or configure names of the devices? 
Maybe I am virt-install blind.
A problem here is that kickstart is in common cases parsed in dracut so 
we can't use %pre to get this info.
   - VM's network IP setup (ie 192.168.107.0/24) to have reasonable 
values for checking static configurations.

>
>> I am wondering what resources we'll need to run kickstart
>> tests if only for this issue (and for one NIC case only) I created
>> seven tests. Which made me think whether unit tests wouldn't be
>> more appropriate here. They would be harder to write.
>> And we also want to check that the ks ifcfg file is not only generated
>> but also not overwritten by dracut ifcfg file. And in one of the tests
>> we want to check that ksdevice is honored as default --device (actually
>> Jiri has a patch making this work), so perhaps really integration tests.
> I think in your tests here, you need to add more stuff to the %post to
> check more stuff on the system.  For instance, you are checking for the
> existence of ifcfg-* files, but not really the content.  Is there
> something in those files that can be checked to verify anaconda did what
> you wanted it to do?

The thing is that by this I didn't intend to test if the hostname was 
actually configured, or the network config (dhcp) was actually applied, 
but rather whether the device configuration was set up (ifcfg 
configured) in dracut (ie checking the content for comment indicating 
that). This way I also test that dracut's write-ifcfg didn't overwrite 
these ifcfgs before switchroot. I thought it would be clear from 
comments in kickstart and fail messages.

For example, I want to test that for

ksdevice=link
network --hostname=blah

a device (first device with link found, ie the same as if we supplied 
--device=link) would be configured in dracut.

but for

network --hostname=blah

(no ksdevice) we don't attempt to configure any device as it is just 
hostname configuration

and for

network --hostaname=blah --activate

(or any other option in place of --activate)
we configure a device (default --device=link) in dracut.


Ie I am mainly testing the logic in parse-kickstart works ok (but also 
relation to ksdevice setting, and not overwriting ifcfg files by dracut 
before switch-root), that is why I was thinking about unit tests for the 
logic (in parse-kickstart, not network.py).


Now I think it makes sense to check more (eg the actual configuration) 
here too (ie values in ifcfg file are really those that was desired by 
the kickstart config - dhcp in this case). I wanted to keep the tests 
testing just the one thing I want to test - which occurs to me now as 
not a good approach for integration tests (as opposed to unit tests). 
Instead, I should probably check for as much as I can during one test, 
right?

>
> Finally, I think Jiri already covered the hostname part, right?

Unlike me he is testing that the hostname is actually set but having 
said the above I think I should merge his test with mine?


Radek


More information about the anaconda-patches mailing list