vmbuilder team mailing list archive
-
vmbuilder team
-
Mailing list archive
-
Message #00009
Re: VMBuilder plans
Gosh, this is embarrassing. When I set up this mailing list, I
apparantly did not get subscribed to the list myself. :(
/me catches up straight away.
On Fri, 11 Sep 2009 23:02:05 +0200, Andreas Heck wrote:
> Do you have any specific ideas for the new architecture of vmbuilder?
> Maybe we could use a wiki page to explore and discuss such possible
> architectures in more detail.
I do have a few specific ideas, yes.
The build process will be split into a number of discrete stages. These
include, but are not limited to:
* Preflight check:
This is where each plugin gets a chance to look around the
environment to see if it has the necessary helper programs and
whether the configuration options from the user is sane. This is also
where the plugin can set any defaults that cannot be hard coded (e.g.
which kernel to use for the VM). I got the name from nagios, and am
more than happy to rename it, if anyone has suggestions.
* Create disk images.
* Mount disk images.
* Perform base OS installation (the "debootstrap" stage).
* User setup
* Customisations
* etc., etc.
Something like the existing call_hooks method will be used to call out
to each plugin, allowing it to do whatever it wants at each of these
stages.
A lot of the code that currently is executed this way lives in
VMBuilder/vm.py and VMBuilder/disk.py. disk.py will be turned into a
plugin, and a lot of vm.py will be moved to a Core plugin and a Network
plugin.
This is underway in a branch I've been working on on and off over the
last few weeks, but with the Ubuntu release coming out last week, it's
been very low priority (read: spare time stuff). I hope to get it into a
somewhat working state over the next week or so and will attempt to
split the changes into reasonably sized patches for you all to review
and comment on.
I would also like to be able to tell VMBuilder to stop after a given
stage, and to start from a given stage as well. This has a lot of
advantages. If, for instance, I'm building a lot of slightly differnet
Ubuntu Karmic VM's, it's a waste of time and ressources to start over
each and every time. If I could build a base image (debootstrap + user
setup, etc.), and use that to build all the different ones, just
applying the customisations, that would be awesome.
> What I think to be very important is to kind of negotiate the build
> capabilities of the host operating system and the capabilities and
> requirements of the distribution plugins somehow at startup. vmbuilder
> needs to check which filesystems, bootmanagers and other tools the
> plugins require, which the host system can satisfy and which could be
> satisfied by installing what packages.
This is a very good point. So far, VMBuilder has been made to work with
whatever Ubuntu release it's been included in. I would very much like
for VMBuilder to be a first class project in its own right, separate
from any particular Ubuntu series, and this is just the sort of thing
that needs to be done to support this.
> As I noted when I stumbled over the grub2 bug it could also become
> necessary to repackage some certain tools for use with vmbuilder. I
> may err but as I understand grub2 you need to install different
> packages if you use bios, efi 32/64Bit etc. and you can only have
> installed one at a time because the maintainers only think about
> people who install a boot manager to use them on the machine they
> install it on but don't think about us VM builders.
I think it would be prudent to look at what the installer does here. A
/lot/ of the stuff we do in VMBuilder, the installer does as well, so
there's likely a lot of interesting lessons to be learned there.
> But negotiation and special vmbuilder tool packages also appear very
> interesting to me since apart from seeming necessary to allow
> conceptional clean building of Ubuntu VMs they could also open the
> door to create VM images of every operating system imaginable from
> within Ubuntu, at least as long as there are the right tools available
> to vmbuilder.
Right. I'm hoping the restructuring of the code will make it more
feasible for someone to add plugins to build other distros.
> I think I could aid the design of the new architecture by stress
> testing it against vmbuilder-gui (which is kind of experimental but
> works quite well in my opinion) to see if the new architecture is
> flexible enough to handle other use cases than cli, gracefully. It
> would also be a good idea to not forget about suitability for a web
> gui although we don't have one at the time.
Yeah. The initial plan with VMBuilder was for it to be a library, and
just have the cli as a convenience wrapper. Due to time constraints,
this quickly fell apart. Nowadays, it's quite tedious to use VMBuilder
as a library, but I would like for that to change as well, so that your
GUI code can be decoupled from the CLI interface, and also open the door
to web interfaces.
--
Soren Hansen |
Lead virtualisation engineer | Ubuntu Server Team
Canonical Ltd. | http://www.ubuntu.com/
Attachment:
signature.asc
Description: Digital signature