On Wed, 29 Jun 2011 11:51:18 +0100, Zygmunt Krynicki zygmunt.krynicki@linaro.org wrote:
Hi.
This is just a reminder for Michael but I think it's worth to share that to the rest of the validation team.
When using lava-dev-tool to hack on lava-dashboard or any other component that is based on lava-server the location of the database and the actual data contained is easily lost.
You mean
$(python -c 'import lava_server.settings.development as settings; print settings.ROOT_DIR')/development.db
isn't intuitive? :)
I think we need to stop using the "development" settings quickly and switch to django-debian based model where we just use a different configuration file for local development. This would make the testing environment much more similar to production (definitely django-debian would see more testing this way) and would help us locate and control application state.
I would like to propose the following changes:
When hacking lava-server would setup the following stuff (all relative to localenv root).
/etc/lava-server/default_database.conf <- location of the database /etc/lava-server/settings.conf <- django-debian way to alter settings.py /var/lib/lava-server/media/ <- upload root /var/lib/lava-server/static/ <- django-staticfiles root /var/lib/lava-server/database.db (only when using sqlite)
This all looks fine to me.
For postgresql (which I would like to use more by default) this is roughly the same except for default_database.conf pointing at something else than the file mentioned earlier.
I'll see how I can make that happen in practice.
It's one of these things I've been vaguely meaning to look into for ages -- can you run postgres as an unprivileged user like this for testing? I assume it's possible in some sense, but if e.g. it involves recompiling postgres or any thing like that it's not really practical. But I would be happy to only support postgres.
Cheers, mwh