On Mon, 25 Jan 2016, Andrew Cagney wrote:
I've now twice tracked a test VM's slow boot (<30s -> >1minute) down to the Python (I'll get to that in a moment) script "swan-transmogrify" that is run, every time the machine is booted, from "/etc/rc.d/rc.local". The first slow down I encountered was tracked down to "chcon -R --reference /var/log /testing/pluto"; and
that's to prevent selinux warnings inside the guest. It could possibly be commented out. Maybe Tuomo can fix it better.
the latest, I suspect, is with "systemctl restart network.service" interacting with some tools needed for Kerberos.
The network restart is because it reconfigured the "base" VM into one of the known guests "west, east, etc".
Well, according to https://libreswan.org/wiki/Test_Suite#swan-transmogrify "This python script compares the nic of eth0 with the list of known MAC addresses from the XML files. By identifying the MAC, it knows which identity (west, east, etc) it should take on. Files are copied from /testing/baseconfigs/ into the VM's /etc directory and the network service is restarted. " That sounds like a simple "first-boot" like operation; not something that needs to be done every time, and not something requiring MAC magic. In fact, we could even run something like:
Yes. But the original idea was that we would be using a single image (eg uml disk) and use a copy-on-write to transmogrify it into west,east, etc and then throw away the COW at the end of the test. This to ensure no state is left behind for the next test. But you are right, with KVM we deviated a little bit from this. But I think for the docker tests Antony did, it might still be needed because those images are created from scratch for each test.
i.e., initiate the transmogrification (google thinks that is a word!) once, from outside the VM, and with an explicit host name. No need for any MAC magic, and no need for repeated fiddling with config files or restarting networks during every boot.
We do need to ensure some files are always correct for that test, such as resolv.conf that might be different for different tests. But in general, yes we could probably get away with that for the KVM tests. We also always create the NSS database from a known saved copy that only contains the raw RSA key. Some tests need a cert added, some tests need to get that cert via IKE. So it is important to always cleanup the NSS and start from the minimal one.
Who knows. It contains docker magic. It silently runs random processes. And it's written in Python and not SH (boot scripts IMNSHO should be simple SH).
Shell sucks for variables and sub shells and automating interactive things :P
However, what I suspect is that it has, over time, it has out-of-site-out-of-mind accumulated stuff that really really needs to be transparent and initiated from the "*init.sh" scripts. For instance, both swan-transmogrify and swan-prep screw around with the contents of /etc/ipsec.d/*.
thoughts, Andrew PS: Why are the VMs running NFS; and why do the VMs suck down useless megabytes of debuginfo RPMs :-)
We weren't sure if we were moving the 9P filesystem to NFS or not. 9P is nice because it works even if OE screwed up the network. But 9P is not writable in RHEL (by design) and it seems slower than NFS by a lot. But NFS can go down when the networking gets screwed up by IPsec. So for instance we could lose logging. debuginfo is needed to get proper gdb backtraces :P But you know that :P Paul _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
