Those of you who have been around for a while will know that we used to package LAVA as Debian packages. This had its problems and we switched over to the world of pip and virtualenv and lava-deployment-tool.
Unfortunately, pip and virtualenv have not really given us the control we need to be confident in our deployments, and so I'm proposing to change again, this time to zc.buildout. This is less of a change than the switch away from debs -- instances of LAVA will still be a concept and the lava-deployment-tool script will still be used, at least for now.
The way buildout works is that there is a config file that specifies how -- reproducibly! -- to assemble various pieces into a deployment. I have a branch of lava-server at lp:~mwhudson/lava-server/use-buildout that contains such a config file (and various other related bits and pieces), and a branch of lava-deployment-tool that creates a buildout-based deployment.
An instance on disk in the new world is similar to but not the same as an instance is today. In particular it is not a virtual environment -- although for compatibility, it looks like one. There is still a $LAVA_INSTANCE/bin/activate script that you can source in bash to put that instance's scripts at the front of your $PATH. Inside an instance, the etc, run, tmp and var directories server the same function as they do today. There is also a new directory, code. The code directory contains a number of subdirectories, one for each revno of lava-server that has been installed into that instance, and a symlink 'current' that points to the currently active one.
There are now two merge proposals on LP:
https://code.launchpad.net/~mwhudson/lava-server/use-buildout/+merge/109768 https://code.launchpad.net/~mwhudson/lava-deployment-tool/use-buildout/+merg...
I've made an effort to update the documentation in l-d-t's README, and I've put an htmlified version of this file online at http://people.linaro.org/~mwh/ldt.html so that might be a good place to start.
Cheers, mwh