VMBuilder in Lucid == lots of fail

Let it be no secret that I’m unhappy with the state of VMBuilder in Lucid (and in general for that matter). Way too many regressions crept in and I didn’t have time to fix them all. I still expect to do an SRU for all of this, but every time I try to attack the bureaucracy involved in this, I fail. I need to find a few consecutive hours to throw at this very soon.

Anyways, in an effort to make testing easier, I’ve set up a PPA for VMBuilder.

I’ve set up a cloud server that monitors the VMBuilder trunk bzr branch. If there’s been a new commit, it rolls a tarball, builds a source package out of it, and uploads it to that ppa. That way, adventurous users can grab packages from there and test things out before they go into an SRU. To do this, you simply run this command:

sudo add-apt-repository ppa:vmbuilder/daily

I’m also working on a setup that will automatically test these packages. The idea is to fire up another cloud server, make it install a fresh VMBuilder from that ppa, perform a bunch of tests and report back. To do this, I’m injecting an upstart job into the instance that

  1. adds the ppa,
  2. installs vmbuilder,
  3. builds a VM, which (using the firstboot option) will call back into the host when it has booted succesfully,
  4. sets up a listener waiting for this callback,
  5. waits for set amount of time for this callback.

If I get a response in a timely manner, I assume all is well. If not, it’ll notify me somehow.

The idea is to make it run a whole bunch of builds to attempt to exercise as much of the code base as possible.

I’ll try to make a habit of blogging about the progress on this as I know a lot of people are aggravated by the current state of affairs and this way, they can see that something is happening.

9 thoughts on “VMBuilder in Lucid == lots of fail

  1. Yann

    This is awesome, thanks. The “loop” problem is a bit of a concern to me, as the only way I found to fix it was to reboot the host. Good luck with the ppa :)

    PS: What about the ubuntu-backports repo? What are the rules for it – maybe it’s easier to push something there?

  2. Soren Post author

    The loop problem is well known and well understood. It’s just a bit tricky to fix, but I hope this much shorter “write code -> get someone to test things” cycle will help that somewhat.

    As for backports, these are serious problems that need to be SRU’ed anyway. Going through backports might be easier, but I’ll still have to do the SRU, so in the end, it’s /more/ work :)

  3. Pingback: Tweets that mention VMBuilder in Lucid == lots of fail | Linux2Go -- Topsy.com

  4. Ralf

    You don’t seem to be the only one, having trouble getting patches or fixes in before the due date and then struggling with the bureaucracy.

    Perhaps, you, with your position, should file a bug report about the process itself.

    Perhaps packages that are not yet stable in their current shape in the repositories shouldn’t need SRU. We seem to assume by default that for every package, the version in the repository at the feature freeze, is stable and usable. What if it isn’t?

    Why would we need an SRU, if the current package fails to build, crashes in the common use-case, or at start-up. I think by default packages should all be labelled unstable; and then an army of volunteer testers can give thumbs-up. The packages that are get a thumbs-up are considered stable and are locked at feature-freeze.

    For the other packages that are still marked unstable, but are in ‘main’, there should be a week or so, where the issue either is resolved or the package should move out of main.

    Your case is a clear example: updating the repository versions for your versions is no-risk. Because the current versions are barely usable as it is. If it is impossible to introduce a regression, why all the paper work?

    Just my two cents.

    And you, with your position, if you find merit in these ideas, are more likely to be able to get the much needed changes in the policy.

    And these are just baby steps. If Canonical would seriously consider turning the universe into a rolling repository, and only ‘locking’ main; i think that most people would welcome such a change and that there would be much less third party PPA’s in everybody’s sources.list.

  5. Pingback: Hudson and VMBuilder | Linux2Go

  6. Joakim

    Hi, vmbuilder is a productive tool for people deploying lots of vm’s. And there is also those who have policies regarding PPA’s. Can you please elaborate about the plans for fixing the issues mentioned for vmbuilder on Lucid?

  7. Soren Post author

    The plan is still to get VMBuilder into lucid-updates. The SRU process is just a bit heavyweight, so I’d like to reduce the number of times I have to through it.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>