[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