← Back to team overview

vmbuilder team mailing list archive

VMBuilder plans

 

Hi, everyone.

If you don't know me, I'm Soren Hansen, I wrote the original bash
implementation of VMBuilder, and also wrote and maintain the Python
implementation.

I'm still excited about the project, even though I've had extremely
little time to work on it for the last many months, and as such haven't
had much chance to review patches and give feedback.

I hope to be able to change that going forward, and also make some
procedural changes that should make me less of an obstacle to getting
things done.

= Merges and reviews =

The first change I'd like to implement is to make the VMBuilder team
(this team) the default review team for merge proposals for VMBuilder.
This means that new merge proposals will be sent to all members of this
team, and everyone can (and should!) comment and vote on them. Both
reviewer and submitter become better developers by reviewing code.
Everybody wins. Unless someone objects, I'll make this change early next
week.

= Cleanup and restructuring = 

As anyone who's tried to write a patch for VMBuilder will know that it's
a rather complex code base. Some parts are simply complicated, other
parts are confusing because they are where they are purely for
historical reasons.  Other parts again have simply grown unwieldy over
time. I would like for this to change. The goals are to make VMBuilder
more easily extensible and to make it easier to come along as a new
contributor and write patches.

To accomplish this, I have a few ideas:

== Event driven VM building ==

At the moment, VMBuilder's workings are quite static. It starts by
setting up a directory structure for the build, creating the disk
images, partitions and filesystems, and mounts them. It then asks the
distro plugin to do whatever it needs to do to create the VM (which
involves a *lot* of steps that are also "static").  When that returns,
it unmounts everything, converts the disk images to the target format,
optionally deploying the disk image somewhere, cleans up after itself,
and terminates.

As an alternative approach to this, I'll be adding some kind of hook or
event mechanism that will make it much easier for plugins to do
interesting things to the build, and the code should hopefully end up
more readable and straightforward as a result.

== Unit tests and TDD ==

I've recently developed a small crush on unit tests, and I've started
writing some for VMBuilder. Having an extensive set of unit tests will
make it easier for new contributors to add new code, as they will be
able to quickly test if they've broken any of the existing code. If they
manage to break something that the unit tests do not catch, we've simply
not written good enough unit tests :)

If any of you have experience writing unit tests or with Test Driven
Development (TDD), I'd love to get your help. I'm still very much a
rookie unit test author, but I very much believe it will make a dramatic
impact on the future development of VMBuilder.

-- 
Soren Hansen                 | 
Lead virtualisation engineer | Ubuntu Server Team
Canonical Ltd.               | http://www.ubuntu.com/

Attachment: signature.asc
Description: Digital signature


Follow ups