Quoting Jean-Baptiste Lallement ([email protected]): > On 07/03/2013 11:53 AM, Robie Basak wrote: > >I scratched an itch and implemented an adt-virt-lxc, as I couldn't find > >that anybody else had worked on it. > > > >It's here: https://code.launchpad.net/~racb/ubuntu/saucy/autopkgtest/lxc > >Or just grab the adt-virt-lxc binary from it, and run: > > autopkgtest (...) --- /path/to/downloaded/adt-virt-lxc saucy -s daily > > > >It uses the ubuntu-cloud LXC template. It assumes that you have > >permission to "sudo lxc-{create,start,attach,stop,destroy}" which works > >fine on cloud images. > > > > >So LXC seemed like a good solution. Now I can write tests for daemons > >more easily. > This is a great feature added to autopkgtest. Thanks for this work! > > > > > > >A couple of issues with my code, which I'd like to fix with some > >feedback: > > > >1. I currently hardcode the container name "test". How do I create a > >unique new container name without racing to create it? A question for > >Serge perhaps? > You could use a slightly different approach but which in my opinion > fits well with autopkgtest. > What if you use an existing container as base and start an ephemeral > container to run the tests on. > > A first step would be to create the container outside of the > virt-lxc driver with the same command you use in the driver > currently: > lxc-create -t ubuntu-cloud -n adt-base -- -i adt ... > > Then start an ephemeral container with: > sudo lxc-start-ephemeral -o adt-base -kd > > (-k is important for point 2 as it gives you access to the > underlying filesystem (maybe there is a way I dont know with tmpfs > too) and for some tests you'll need more than the space available in > tmpfs to run your tests) > > ephemeral containers will save you the time of re-creating the > container for each test and an easy way to revert to a base image > with always the same state.
That sounds like an excellent solution. The only dowside is that historically sometimes overlayfs has gotten finicky especially when playing with apparmor. But I think those issues are all resolved now. Otherwise, I'd just use mktemp. > >2. How do I detect when the container is fully booted so that I can use > >it? Using lxc-wait only gave me it from (I presume) the host's > >perspective; the guest kept breaking things until I figured out that it > >was cleaning /tmp after I had already started using it. For now, I've > >got a sleep hack to avoid this. But how do I detect boot completion > >properly? A question for Scott maybe? > On first boot of the container, from the host and if you used an > ephemeral container, you can monitor when the file > /var/lib/lxc/<NAME>/delta0/var/lib/cloud/instances/lxc-*/boot-finished > appears. > > -- > Jean-Baptiste > IRC: jibel -- Ubuntu-quality mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
