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.
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)
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.
Thanks ZK
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
On Thu, Jun 30, 2011 at 3:01 AM, Michael Hudson-Doyle < michael.hudson@linaro.org> wrote:
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.
If we're just talking about doing this testing periodically, and not every
time you run the unit tests, could we just do it in a chroot?
-Paul Larson
On Thu, 30 Jun 2011 14:45:28 +0100, Paul Larson paul.larson@linaro.org wrote:
On Thu, Jun 30, 2011 at 3:01 AM, Michael Hudson-Doyle < michael.hudson@linaro.org> wrote:
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.
If we're just talking about doing this testing periodically, and not every time you run the unit tests, could we just do it in a chroot?
I'm talking about trying to get to the situation where we can use a self-contained postgres for our unit tests, so that we can move to only supporting postgres. If we can't do that, then yes, some kind of chroot solution makes sense.
Cheers, mwh
-
Michael Hudson-Doyle -
Paul Larson -
Zygmunt Krynicki