Re: Request for comments on a new Open Source Paas platform for Django

[Michael]

On Sunday, 3 March 2013 17:45:56 UTC+1, Bruno Girin wrote:

The main stumbling block at the moment and for which we could do with Django expertise is about the structure of the settings files. Some settings are application specific and should be left alone by Juju, others are environment specific and should be generated by Juju (database config for instance). Patrick solved that problem by separating different config elements in different files but this implies that juju'ised applications would need to follow the same structure. Is that a good idea?

I had a go at something similar a while back [1] (well, a very cut-down version of what you guys are attempting), and for that I used configglue's in-built support for local settings that override the project settings [2], but I'm assuming in this case we'd not want to force juju'ised projects to use configglue either.

I've not tried this on any production app, or thought about it more than the example below - perhaps others can say the obvious issues they see - but one idea that comes to mind is just reversing how people normally split up their settings files, something like:

{{{

$ django-admin startproject test_settings

$ cd test_settings/

$ echo 'from django.conf import settings;print("Debug is: %s. LangCode is: %s" % (settings.DEBUG, settings.LANGUAGE_CODE))' | ./manage.py shell --plain

(prints "Debug is: True. LangCode is: en-us")

$ echo -e "from test_settings.settings import *\nDEBUG = False" > local_settings.py

$ echo 'from django.conf import settings;print("Debug is: %s. LangCode is: %s" % (settings.DEBUG, settings.LANGUAGE_CODE))' | ./manage.py shell --plain --settings=local_settings

(prints "Debug is: False. LangCode is: en-us")

}}}

-Michael

[1] http://micknelson.wordpress.com/2011/11/22/a-generic-juju-charm-for-django-apps/

[2] http://bazaar.launchpad.net/~michael.nelson/charms/oneiric/apache-django-wsgi/trunk/view/head:/hooks/manifests/database_settings.pp

[Dave Murphy]

On Sunday, March 3, 2013 4:45:56 PM UTC, Bruno Girin wrote:

Patrick solved that problem by separating different config elements in different files but this implies that juju'ised applications would need to follow the same structure. Is that a good idea?

If you're aiming for a PaaS-style charm for Django, then trying to emulate The Twelve-Factor App [1] and it's opinions on configuration [2] would be a good starting point. Basically, if there are things specific to the environment then they should be in environment variables, not in generated or modified config files.

 

[Michael Nelson]

+1 - but Django doesn't support env vars overriding settings out of the box (although configglue does enable this) which means forcing people using the charm to update their settings (rather than just encouraging good practise). That said, it might be a small (and worthwhile) thing to ask of people wanting to use the charm. (ie. to use this charm, your settings need to read the following env vars...) If not, writing a local_settings.py that overrides the required settings from the env may work:

local_settings.py:

{{{

import os

from userproject.settings import *

LANGUAGE_CODE = os.environ['DJANGO_LANGUAGE_CODE']

...

}}}

Are there other better options that wouldn't force people to change their code to use the charm?

[Dave Murphy]

On Tuesday, March 5, 2013 1:17:13 PM UTC, Michael wrote:

Are there other better options that wouldn't force people to change their code to use the charm?

For the charm to be of sufficient value, it needs to be opinionated, otherwise it's going to suffer from trying to work out-of-the-box for everyone.

[Bruno Girin]

True but using environment variables only moves the problem somewhere else: it means that you still need to auto-generate the part of the startup script that sets the environment variables. Besides, as said above, it would force django app developers to explicitly use those environment variables and if they forget one of misspell it, the danger is that it would fail silently. Then the risk is that it's hard to debug because you're hunting setting values in two places: the django settings and the startup scripts that sets the environment variables.

So I'd much rather have the charm auto-generate part of the config in a sensible way and then tell people: if you use Juju, don't provide those settings in your config, the charm will do it.

Bruno

[Christopher Glass]

For what it's worth, "other PaaS solutions" solve this by letting people call a python function from settings.py

I think it's a good solution.

--
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/979lJojyxs0/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dave Murphy]

On Tuesday, March 5, 2013 7:03:36 PM UTC, Bruno Girin wrote:

So I'd much rather have the charm auto-generate part of the config in a sensible way and then tell people: if you use Juju, don't provide those settings in your config, the charm will do it.

...and if they do? How is this any different to the code not handling environment variables correctly?

People are going to need to adapt their project to the charm no matter what approach you take.

[Bruno Girin]

True. My point here is that if you ask people to adapt their project to work in Juju, it's easier for them and less error prone to say "don't provide this bit" than say "provide this bit in this particular way".

I quite like Christopher's suggestion of calling a python function from settings.py too.