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
On Tue, Jun 12, 2012 at 05:07:14PM +1200, Michael Hudson-Doyle wrote:
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
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
Hi Michael,
I am currently using virtualenv and pip manually to "deploy" lava-server and lava-dashboard on my computer, so I can work on the Graphics dashboard extension. I am not using l-d-t as it brings in too many dependencies (databases etc) which I don't need (nor want) running on my development box.
Will the change to zc.buildout affect this use case?
Thanks, Alexandros
Hi Michael,
On Tue, 2012-06-12 at 17:07 +1200, Michael Hudson-Doyle wrote:
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.
As I never worked with buildout before I was wondering if there was a discussion around this topic before deciding to adopt this new deployment approach. I would like to read that and see what was discussed and what are the main advantages of changing how to deploy Lava once again. Is it available somewhere?
In case this change really happen, I believe that would be nice to have some sort of tutorial teaching how to migrate your current setup and deploy it with buildout, without loosing your database, etc.
Also, I remember to have long conversations on IRC with you guys and IIRC there was an agreement that Lava would also be released as deb packages again, so we would have an option to use pip or debs. How is that going?
Please, forgive me if I missed any important discussion.
Thanks in advance.
BR,
-Abner
Cheers, mwh
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
After a couple more days of hacking and bugfixing, I would like to invite you all to test my lava-deployment-tool branch again:
https://code.launchpad.net/~mwhudson/lava-deployment-tool/use-buildout/+merg...
(Please test revno 238 or newer; you'll need to run lava-deployment-tool setup again).
The main changes are support from upgrading from pip-based instances and a simpler story for local development:
http://people.linaro.org/~mwh/ldt.html#local-development
In particular the buildout configuration now live in its own branch, lp:lava-manifest.
If you run jobs through the scheduler, you'll notice that the logging in the log files isn't quite right; that's fixed by https://code.launchpad.net/~mwhudson/lava-dispatcher/lava-space-dispatch-com...
Cheers, mwh
Michael Hudson-Doyle michael.hudson@linaro.org writes:
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. ...
linaro-validation@lists.linaro.org
-
Abner Silva -
Alexandros Frantzis -
Michael Hudson-Doyle