*** sshnaidm has quit IRC | 01:33 | |
*** sshnaidm has joined #ara | 01:35 | |
*** herald85 has joined #ara | 07:08 | |
*** apollo13 has quit IRC | 08:36 | |
*** apollo13 has joined #ara | 08:39 | |
*** herald85 has quit IRC | 09:06 | |
*** herald85 has joined #ara | 10:50 | |
*** gvincent has quit IRC | 12:01 | |
*** dbpiv has joined #ara | 12:41 | |
*** zbr|ruck is now known as zbr|rover | 12:44 | |
*** herald85 has quit IRC | 15:36 | |
dmsimard | apollo13: django question | 19:16 |
---|---|---|
apollo13 | shoot I am fighting go | 19:16 |
dmsimard | in ara 0.x we have a "special" wsgi app: https://ara.readthedocs.io/en/stable-0.x/advanced.html | 19:16 |
dmsimard | This is what makes us able to upload ansible.sqlite as artifact in the job logs and make this work: http://logs.openstack.org/29/664129/1/check/ansible-role-ara-tests-fedora-2.7/a5278f6/ara-report/ | 19:17 |
dmsimard | tl;dr, it maps "29/664129/1/check/ansible-role-ara-tests-fedora-2.7/a5278f6/ara-report/" to /some/logserver/path/29/664129/1/check/ansible-role-ara-tests-fedora-2.7/a5278f6/ara-report/ and defines ARA_DATABASE as /some/logserver/path/29/664129/1/check/ansible-role-ara-tests-fedora-2.7/a5278f6/ara-report/ansible.sqlite | 19:18 |
dmsimard | it's a bit hacky and was designed to work with the flask backend: https://github.com/ansible-community/ara/blob/stable/0.x/ara/wsgi_sqlite.py | 19:19 |
apollo13 | I see | 19:19 |
dmsimard | We had to do this because 1) html generation didn't scale (way too many small files) and 2) because openstack runs >1 million playbooks per month | 19:20 |
dmsimard | We have an additional challenge in 1.0 where ara-web is decoupled and expects an API endpoint | 19:20 |
dmsimard | whereas in 0.x, the web app was bundled | 19:20 |
dmsimard | I've been searching how we might end up implementing something similar with django but my google fu has been failing me | 19:22 |
apollo13 | so yes, you can always write your own wsgi middleware which calls settings.configure() appropriately | 19:23 |
apollo13 | https://docs.djangoproject.com/en/2.2/topics/settings/#django.conf.settings.configure | 19:23 |
apollo13 | actually no | 19:23 |
apollo13 | it will break your neck if you have more than one database file | 19:23 |
dmsimard | apollo13: it would only ever be one database file, though | 19:25 |
dmsimard | just different (dynamic?) files based on the requested path | 19:25 |
apollo13 | yeah, but you can just configure django once | 19:25 |
apollo13 | inside one process | 19:25 |
dmsimard | apollo13: so a wsgi app that fires django with the right settings ? | 19:27 |
apollo13 | no chance | 19:27 |
apollo13 | you can only fire it up once | 19:27 |
apollo13 | ie for one path | 19:27 |
apollo13 | after that django is configured and won't like you if you try to tell it to use a different database | 19:28 |
dmsimard | so it would need to be different instances of django eh | 19:29 |
apollo13 | and different instances of django means actual different unix processes | 19:29 |
dmsimard | apollo13: a custom database engine that extends the sqlite backend to use an arbitrary database post-settings ? | 19:33 |
dmsimard | (I'm spouting nonsense but trying to come up with ideas) | 19:34 |
apollo13 | will probably work, but you need to put the location in a thread local and be very careful | 19:34 |
dmsimard | Is the problem is that once settings.py is loaded, it's game over ? | 19:34 |
apollo13 | django has global state, there can only be one django per process | 19:35 |
apollo13 | and yes settings are just configured once | 19:35 |
dmsimard | right, so really what we need is a way to load an arbitrary database location after settings have loaded | 19:35 |
apollo13 | which would mean a custom db backend and a middleware which puts all that stuff into thread locals and very very careful configuration because django usually keeps the connection open | 19:36 |
apollo13 | note: you are steering into completly unsupported waters | 19:37 |
dmsimard | :D | 19:38 |
dmsimard | need to pick up kids from school, brb | 19:38 |
dmsimard | apollo13: yeah I ideally don't want to swim in unsupported waters -- trying to think outside the box | 19:57 |
dmsimard | a centralized database like postgre or mysql makes sense for some use cases | 19:58 |
dmsimard | the scale at which openstack runs on is a bit much though -- the "one database per job" approach of the sqlite middleware feels like a good fit | 20:01 |
dmsimard | especially in the context of CI jobs | 20:03 |
apollo13 | I guess it would be doable | 20:24 |
apollo13 | just not supported in any way | 20:24 |
apollo13 | I guess I might try writing such a database backend tomorrow, sounds like fun | 20:28 |
*** dbpiv has quit IRC | 20:46 | |
dmsimard | apollo13: found this old snippet that might be worth a try https://djangosnippets.org/snippets/2037/ | 20:47 |
apollo13 | dmsimard: not really, a db router would require that we configure all the databases in settings.py | 20:47 |
apollo13 | but yeah, the middleware part is similar to what I imagine | 20:47 |
dmsimard | there was this thing as well: https://stackoverflow.com/a/14442569 | 20:48 |
apollo13 | that sounds crazy :D | 20:48 |
apollo13 | but probably doable | 20:48 |
apollo13 | although I'd have to check if altering .databases there is threadsafe | 20:49 |
apollo13 | yeah no, .databases is not thread local | 20:52 |
apollo13 | typical SO post, nice in theory but completly flawed | 20:52 |
dmsimard | :D | 20:52 |
*** njt has quit IRC | 21:33 | |
*** njt has joined #ara | 21:33 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!