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
pgpy9hnLwnbFM.pgp
Description: OpenPGP digital signature
_______________________________________________ qa-devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/qa-devel
