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/
signature.asc
Description: Digital signature
_______________________________________________ Mailing list: https://launchpad.net/~vmbuilder Post to : [email protected] Unsubscribe : https://launchpad.net/~vmbuilder More help : https://help.launchpad.net/ListHelp
