This took a bit longer than I had hoped, but I've got proof-of-concept
code for no-cloud disposable clients in libtaskotron.
https://bitbucket.org/tflink/libtaskotron
in the feature/T382-nocloud-disposable branch.
As a warning - this code is still very much in the "may eat babies and
laugh about it" stage (which is why it's in a fork instead of the main
repo). Unless you know what you're doing, you may want to avoid it for
now.
The readme should cover everything you need to make the bits work - the
setup is a bit complex, requires root and disabling selinux enforcing
but it does work :)
One of the reasons for doing this was to get a better idea of where the
potential problems would be. Outside of the wonderful fun that Mike and
I (mostly Mike) have been having with making testCloud work, I think
that the biggest potential problems will be:
- Getting relevant information out of the VM during and after execution
* Do we merge taskotron.log files?
* What's important to grab?
- Error handling
* SSH doesn't easily lend to return codes, making error detection
and handling much more fun
- Managing the VMs so that they use consistent IP addresses
* This'll probably involve some work on testCloud but shouldn't be
a huge problem - mostly solved in setup and irrelevant to the
local execution case
- Managing images
* Where do we put them?
* What images do we use?
* How are they updated?
- Keeping local execution simple
* This would involve quite a bit more complexity in the runner but
I think we need to make sure that the user-facing local execution
case stays simple
* I don't like requiring selinux monkeying or root privileges.
polkit hacking to allow non-root users to use libvirt is one
option but I'd really prefer to avoid that.
The important question at this point is which route we want to take -
use a cloud system with buildbot or this no-cloud route. Both have
their advantages and disadvantages and neither one is going to be
incredibly simple.
I'm still leaning towards the no-cloud option, mostly because I really
don't want to get into openstack deployment management. Yes, there is a
fedora infra managed instance of openstack but I also think assuming we
would never have to help fix/improve that deployment is a bit on the
naive side. The other big advantages in my mind are that the no-cloud
approach makes the local execution much closer to the production
execution model and we'd be much closer to enabling stuff like gnome's
test suite.
I'd appreciate thoughts from other folks on which route they think is a
better approach.
Tim