| *** bcoca has quit IRC | 00:11 | |
| *** Glandos has quit IRC | 04:54 | |
| *** Glandos has joined #ara | 04:54 | |
| *** sshnaidm|pto is now known as sshnaidm|ruck | 05:45 | |
| apollo13 | dmsimard: around :) | 06:56 |
|---|---|---|
| *** apollo13 has quit IRC | 07:05 | |
| *** apollo13 has joined #ara | 07:08 | |
| *** gvincent has joined #ara | 07:30 | |
| *** themroc has joined #ara | 07:48 | |
| *** gvincent has quit IRC | 08:46 | |
| *** gvincent has joined #ara | 08:47 | |
| dmsimard | apollo13: asleep :p | 11:37 |
| apollo13 | awake :รพ | 11:38 |
| dmsimard | Let's catch up later | 11:38 |
| *** jrist has quit IRC | 12:40 | |
| *** tbielawa has joined #ara | 13:06 | |
| *** larivee has joined #ara | 13:56 | |
| *** bcoca has joined #ara | 14:05 | |
| *** jrist has joined #ara | 14:06 | |
| *** jrist has quit IRC | 14:09 | |
| *** jrist has joined #ara | 14:10 | |
| *** jrist has quit IRC | 14:24 | |
| *** jrist has joined #ara | 14:41 | |
| *** tbielawa is now known as tbielawa|mtg | 14:44 | |
| dmsimard | apollo13: ohai | 14:48 |
| dmsimard | so you proposed two different ways for configuration | 14:49 |
| dmsimard | which way do you prefer ? can we talk about the pros/cons of each ? | 14:49 |
| apollo13 | dmsimard: sure, shoot; I prefer the newer one. Gonna ride home. be back in 30 mins or less | 14:50 |
| *** themurph has joined #ara | 14:51 | |
| apollo13 | dmsimard: home | 15:17 |
| dmsimard | apollo13: ohai | 15:19 |
| apollo13 | hi :) | 15:21 |
| dmsimard | I like the approach with everett but I'm not convinced about everett itself | 15:21 |
| apollo13 | okay? | 15:22 |
| dmsimard | what bothers me about everett is that as far as I can see, it's not packaged for any distro and I don't know enough about the project in order to be able to tell if the amount of activity in github is representative of what we might expect if we have any issues with it | 15:24 |
| apollo13 | it is MPL, we can just as well move the two files into ara itself ;) | 15:25 |
| dmsimard | I wear many hats | 15:25 |
| dmsimard | the engineer hat says "sure" | 15:25 |
| dmsimard | the packager/support hat says "hang on" | 15:25 |
| dmsimard | do we want to maintain it, though ? | 15:25 |
| dmsimard | I guess that's what I mean by weighing the pros and cons | 15:26 |
| apollo13 | want? no, but it's 1000 lines and not exactly rocket science | 15:26 |
| apollo13 | that said, if you have a maintained alternative somewhere I am all ears | 15:26 |
| dmsimard | Do know that you're better than me at this so I'm relying on your experience while making sure I understand :D | 15:29 |
| apollo13 | I mean everett is relatively simple python code and basically one file. if it were a C extension then the situation would be different | 15:29 |
| dmsimard | sure | 15:30 |
| apollo13 | but maybe my google fu was to weak; but searching for python and configuration is not the best search term either | 15:30 |
| dmsimard | haha, I bet | 15:30 |
| apollo13 | there might be another fine lib out there, dunno | 15:30 |
| dmsimard | so let me ask you this then | 15:30 |
| dmsimard | what bothers you about the first approach ? | 15:30 |
| apollo13 | that there is no support for config files | 15:30 |
| apollo13 | which granted we could add everett to add that, but: | 15:31 |
| apollo13 | we would then be in the weird situation where we'd still have DJANGO_SETTINGS_MODULE with multiple predefinitions + yet another possible override via ARA_CFG | 15:31 |
| apollo13 | I am somewhat torn between the two approaches | 15:32 |
| dmsimard | django 100% relies on settings.py for everything ? | 15:32 |
| dmsimard | like, out of the box there's nothing else ? | 15:32 |
| apollo13 | yes | 15:32 |
| apollo13 | which is okay imo because that gives the developer the option to do whatever they want as long as they can somehow fill settings.py | 15:33 |
| apollo13 | ie it does not limit you in doing something | 15:33 |
| apollo13 | and the downside of DJANGO_SETTINGS_MODULE is that it has to be in the python path, so you cannot just tell a user to put an ara_settings.py in ~/.config and be done with it or so | 15:34 |
| apollo13 | also if we were to add everett to the first approach you are in the even weirder situation that ARA_CFG would behave differently on which DJANGO_SETTINGS_MODULE is currently active | 15:35 |
| apollo13 | ie if DJANGO_SETTINGS_MODULE is set to dev and ARA_CFG specifies no debug, then it would be True by default, yet if you change DJANGO_SETTINGS_MODULE to prod the same ARA_CFG would result in debug=False | 15:36 |
| apollo13 | which is all understandable but still weird imo | 15:36 |
| apollo13 | that said, one thing speaks for a single settings file: parity between the environments | 15:36 |
| apollo13 | so you do not get into a situation easily where your setup is completly different (like different INSTALLED_APPS because you forgot to change all involved files etc) | 15:37 |
| apollo13 | granted to some extend that can also happen with cfg files | 15:37 |
| apollo13 | as you can see I am torn, there are no perfect solutions; it's probably a matter of taste | 15:38 |
| dmsimard | apollo13: allowing myself to think outside the box for the sake of discussion for a moment | 15:41 |
| apollo13 | sure, by all means | 15:41 |
| dmsimard | you have every right to say it's a crazy idea | 15:41 |
| *** themroc has quit IRC | 15:45 | |
| dmsimard | could we have a set of default settings which allows the API to work | 15:45 |
| dmsimard | and then configure the app through the API | 15:45 |
| dmsimard | behind the scenes, the config could end up in a config file, a database or whatever | 15:45 |
| apollo13 | in theory yes | 15:46 |
| dmsimard | I don't know where I'm going with this or how it would work in practice | 15:46 |
| apollo13 | in practice this approach fails at least for django because settings are not mutable | 15:46 |
| apollo13 | ie you'd have to restart the process to reload database settings | 15:46 |
| dmsimard | ah | 15:46 |
| apollo13 | which may or may not be easy depending on how you deploy | 15:46 |
| apollo13 | but certainly not something you can easily do from inside the app | 15:47 |
| apollo13 | also with my devops hat on: if I do not have a config file that I can deploy with ansible I will hate everything about ara :D | 15:47 |
| dmsimard | devops++ | 15:48 |
| dmsimard | so out of curiosity | 15:48 |
| dmsimard | I looked at horizon, the openstack dashboard project which uses django | 15:48 |
| apollo13 | I like the idea, I just do not think that reconfiguration of the whole running app is doable in django easily (or most other web frameworks in python for that matter) | 15:48 |
| dmsimard | apparently they rely on a single local_settings and it's typically expected in, say, /etc/openstack-dashboard/local_settings | 15:49 |
| dmsimard | I'll keep looking just to see what people are doing | 15:49 |
| apollo13 | so the local settings approach is something not like in the django community | 15:49 |
| apollo13 | the reasoning is simple: | 15:49 |
| apollo13 | generally it means you have a settings.py inside horizon itself which at some point has an "from local_settings import *" | 15:50 |
| apollo13 | right? | 15:50 |
| dmsimard | I suppose | 15:50 |
| apollo13 | ah okay they are doing it a bit more involved https://github.com/openstack/horizon/blob/62d90a49adf608034bd3f8ce94e950f2f30208e2/openstack_dashboard/settings.py#L373 | 15:51 |
| apollo13 | ah no https://github.com/openstack/horizon/blob/62d90a49adf608034bd3f8ce94e950f2f30208e2/openstack_dashboard/settings.py#L376 | 15:51 |
| dmsimard | well, I'm not saying they're doing the right thing | 15:51 |
| dmsimard | I'm saying that's what they're doing :p | 15:51 |
| apollo13 | right, I am just trying to explain why it is not generally liked | 15:52 |
| apollo13 | so basically what you have in local_settings overrides what you have in settings.py | 15:52 |
| apollo13 | but (and this is usually the show stopper): it also means that local_settings cannot extend lists/dicts | 15:52 |
| apollo13 | it can just override | 15:52 |
| dmsimard | ah, because it's an import | 15:53 |
| dmsimard | makes sense | 15:53 |
| apollo13 | the django-native approach would be to set DJANGO_SETTINGS_MODULE to the local_settings (with the caveat of it being in the python path) and then local_settings can do "from base_settings import *" and then extend lists etc | 15:53 |
| apollo13 | so basically inversion of control if you want to look at it like that | 15:53 |
| *** tbielawa|mtg is now known as tbielawa | 16:47 | |
| *** tbielawa is now known as tbielawa|lunch | 17:02 | |
| *** irclogbot_0 has quit IRC | 17:08 | |
| dmsimard | apollo13: do we really need a different config file for differentiating prod/dev ? | 17:22 |
| *** tbielawa|lunch is now known as tbielawa|mtg | 17:59 | |
| *** ara-slack has joined #ara | 18:19 | |
| *** ChanServ sets mode: +v ara-slack | 18:19 | |
| *** tbielawa|mtg is now known as tbielawa | 18:20 | |
| dmsimard | test | 18:20 |
| dmsimard | test | 18:22 |
| *** ara-slack has quit IRC | 18:24 | |
| apollo13 | dmsimard: settings wise? | 18:35 |
| dmsimard | apollo13: ara wise :p | 18:35 |
| apollo13 | imo yes | 18:35 |
| apollo13 | secret_key needs to be secret | 18:35 |
| apollo13 | you don't want to set it during dev though | 18:35 |
| apollo13 | but I also do not want to set a default for prod for it because then users will not change it | 18:36 |
| apollo13 | same goes for debug, it is a security risk in prod (albeit small) but during dev you most certainly want it to be true | 18:36 |
| apollo13 | dmsimard: one option would be an ARA_ENVIRONMENT variable which basically set a few defaults, this way we could get rid of dev.cfg/integration.cfg and test.cfg | 18:40 |
| apollo13 | I actually would like that :) | 18:40 |
| apollo13 | ARA_CFG would still be evaluated, but ARA_ENVIRONMENT=prod|test|dev etc would set sensible defaults where allowed | 18:41 |
| *** Naphtime has joined #ara | 18:41 | |
| apollo13 | dmsimard: if you were to let it be my choice I'd also add ARA_ENVIRONMENT to https://review.openstack.org/#/c/612446/ and go with that. but in the end I can live with whatever approach you like most | 18:44 |
| apollo13 | bbl, dinner | 18:48 |
| *** tbielawa has quit IRC | 18:48 | |
| *** Naphta has quit IRC | 18:48 | |
| *** tbielawa has joined #ara | 18:50 | |
| *** irclogbot_0 has joined #ara | 19:27 | |
| *** irclogbot_0 has quit IRC | 19:27 | |
| dmsimard | apollo13: I need to prepare for an ansible meetup, I'll think about it | 19:32 |
| *** irclogbot_0 has joined #ara | 19:32 | |
| *** tbielawa has quit IRC | 19:56 | |
| *** irclogbot_0 has quit IRC | 20:21 | |
| Xaroth | apollo13: django does not require a settings.py | 20:34 |
| *** gvincent has quit IRC | 20:35 | |
| *** gvincent has joined #ara | 20:35 | |
| Xaroth | `django.conf.settings.configure(**options)` does the function of what settings.py would | 20:36 |
| Xaroth | you have projects like https://github.com/simonw/djng that make django work for single-file applications (a-la flask) | 20:36 |
| Xaroth | so you can easily prepare the configuration as required by django in your bootstrapper | 20:37 |
| Xaroth | just make sure that your code doesn't touch django until it has configured it | 20:38 |
| *** irclogbot_0 has joined #ara | 20:43 | |
| *** irclogbot_0 has quit IRC | 20:43 | |
| *** irclogbot_0 has joined #ara | 20:48 | |
| *** irclogbot_0 has quit IRC | 20:48 | |
| *** openstack has quit IRC | 21:03 | |
| *** openstack has joined #ara | 21:05 | |
| *** ChanServ sets mode: +o openstack | 21:05 | |
| *** irclogbot_0 has joined #ara | 21:46 | |
| *** irclogbot_0 has quit IRC | 21:46 | |
| *** themurph has quit IRC | 21:48 | |
| *** irclogbot_0 has joined #ara | 21:48 | |
| *** irclogbot_0 has quit IRC | 21:50 | |
| *** irclogbot_0 has joined #ara | 21:58 | |
| *** irclogbot_0 has quit IRC | 21:58 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!