Hey Guys,
I was thinking about adding some documentation for LAVA roughly based on the presentation I did last week. Paul mentioned during the presentation that my suggestions of using virtualenv and pip commands were no longer needed and that you could use lava-deployment-tool.
I just started to play with lava-deployment-tool on my dev box, but stopped. After patching it to support Ubuntu Precise, the tool wanted to start installing lots of things(like apache) and make changes to my system (like upstart jobs).
It seems to me lava-deployment-tool is really cool, but is more for production and not for a more simple scenario where you just want to prototype some changes.
Is my conclusion wrong, or do you guys think its still worth documenting my scenario, where you use virtualenv and a few pip commands? I think documentation like this would end with a "next steps: lava-deployment-tool".
-andy
Hi Andy
Not using l-d-t is very much possible _but_ as we grow it will be harder and less likely to work. A plain virtualenv will obviously work (l-d-t also sets one up) as long as you don't care about performance and don't plan to use the scheduler.
Best regards ZK
On Wed, Feb 15, 2012 at 6:52 PM, Andy Doan andy.doan@canonical.com wrote:
Hey Guys,
I was thinking about adding some documentation for LAVA roughly based on the presentation I did last week. Paul mentioned during the presentation that my suggestions of using virtualenv and pip commands were no longer needed and that you could use lava-deployment-tool.
I just started to play with lava-deployment-tool on my dev box, but stopped. After patching it to support Ubuntu Precise, the tool wanted to start installing lots of things(like apache) and make changes to my system (like upstart jobs).
It seems to me lava-deployment-tool is really cool, but is more for production and not for a more simple scenario where you just want to prototype some changes.
Is my conclusion wrong, or do you guys think its still worth documenting my scenario, where you use virtualenv and a few pip commands? I think documentation like this would end with a "next steps: lava-deployment-tool".
-andy
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
On 02/15/2012 12:00 PM, Zygmunt Krynicki wrote:
Hi Andy
Not using l-d-t is very much possible _but_ as we grow it will be harder and less likely to work. A plain virtualenv will obviously work (l-d-t also sets one up) as long as you don't care about performance and don't plan to use the scheduler.
For me, when I start with something new I want something that's not going mess with my computer in ways I don't yet understand. I think it would be a real plus and goal to keep things in a way that this type of model can be used. There are obviously things like the scheduler where that probably can't be avoided. However, I'm guessing a number of LAVA consumers are going to be like me. They want to create a test and possibly tweak a view of the data.
I think there might be 4 paths to help guys in my situation:
1. The approach I've been doing which may not work down the road
2. Update l-d-t to support some type of "develop" mode which does what 1 attempts
3. A new script lava-develop-tool. Its like 2 but splits things out into a new script. Just suggesting this in the event people like 2, but don't think its maintainable.
4. Tell me to stop being anal-retentive, grow up, and use the tool.
I can see good arguments for all options :)
-andy
On Wed, Feb 15, 2012 at 7:15 PM, Andy Doan andy.doan@canonical.com wrote:
On 02/15/2012 12:00 PM, Zygmunt Krynicki wrote:
Hi Andy
Not using l-d-t is very much possible _but_ as we grow it will be harder and less likely to work. A plain virtualenv will obviously work (l-d-t also sets one up) as long as you don't care about performance and don't plan to use the scheduler.
For me, when I start with something new I want something that's not going mess with my computer in ways I don't yet understand.
This is why we have virtual machines.
I think it would be a
real plus and goal to keep things in a way that this type of model can be used. There are obviously things like the scheduler where that probably can't be avoided. However, I'm guessing a number of LAVA consumers are going to be like me. They want to create a test and possibly tweak a view of the data.
I think there might be 4 paths to help guys in my situation:
1. The approach I've been doing which may not work down the road
2. Update l-d-t to support some type of "develop" mode which does what 1 attempts
It already has such mode. But it still depends on postgresql and apache. Not using those two components simply makes no sense. We don't want people to develop against one stack and deploy on another stack. Even my netbook can run one instance without any issues.
Very soon we will also depend on rabbitmq. Sadly web applications are not trivial hello world programs. Because lava is quite modular some of the 'bigger' components may be left out. There is some degree of tinkering that is sensible with virtualenv/sqlite/django-http-server but it is not our primary target.
Instead of a development mode that is lighter I'd like better administration UI. Use curses interface. Redo the UI so that using instances is easy and obvious, etc. Patches welcome, as always (I hope this does not sound rude and dismissive, I really want patches, this _is_ a project open for participation)
3. A new script lava-develop-tool. Its like 2 but splits things out into a new script. Just suggesting this in the event people like 2, but don't think its maintainable.
4. Tell me to stop being anal-retentive, grow up, and use the tool.
I can see good arguments for all options :)
-andy
linaro-validation@lists.linaro.org
-
Andy Doan -
Zygmunt Krynicki