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
On Wed, 21 Jan 2015 11:06:02 -0700 Tim Flink tflink@redhat.com wrote:
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 :)
For anyone who has already tried the PoC code - you may want to change the testCloud repo to use my fork [1] instead of the upstream. Mike is planning some non-backwards-compatible changes to the library and this will let me update once the changes are done instead of constraining what upstream is doing when.
Tim
From: "Tim Flink" tflink@redhat.com 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.
From the Beaker side, one of the big reasons we went down the path of providing the "virt/image-install" task is because we don't yet have an ETA on when we'll drop the "experimental" tag from our OpenStack integration. So unless you have a particularly compelling need to do multi-host test orchestration, sticking with virt guests on a single host sounds like a good option to me.
The other thing that may potentially let you do is IPv6-only testing of your guests, even if nothing else on your network supports IPv6-only operation.
Cheers, Nick.
On Wed, 21 Jan 2015 11:06:02 -0700 Tim Flink tflink@redhat.com wrote:
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.
I've continued to poke at this to add functionality that we don't already have in libtaskotron. To show this off, I wrote a throwaway task for testing cloud images:
https://bitbucket.org/tflink/task-democloudcheck
The code and output are still pretty ugly but it does work with F21 cloud images (still waiting for rawhide cloud images that work to test that). The latest code from my libtaskotron branch is also needed. I purposely didn't use a real test harness for the task so I could get it done quickly but I don't want to be supporting tasks written like this in production :)
Feedback on the direction of these changes would be welcome. Especially from the folks who are going to end up working on the feature.
Tim
qa-devel@lists.fedoraproject.org
-
Nick Coghlan -
Tim Flink