Django charms [Was: Re: [ubuntu-cloud] Ubuntu cloud use case]

[Bruno Girin]

On 21/09/12 20:45, Bruno Girin wrote:
> On 20/09/12 19:32, Mark Mims wrote:
>> <snip>
>> Please by all means help with Django!!  I'm not sure what extra features
>> / connections we should add to it at this stage and need input from
>> peeps who're running it in production.
> I will do. I'll probably start working on that in the next few weeks and
> will tell you how I progress.

Right, I've had a look and I need advice on how to proceed. If I look at
what exists today, I find a django-rainbow charm [1], an initial
Launchpad bug for a Django framework charm [2] initially worked on by
Mike Nelson, an additional bug for a python-django with WSGI container
charm [3] created by Patrick Hetu as a result of his idea on using a
WSGI subordinate and a blog post from Michael Hall [4] who is looking at
charming the app rather than the framework.

Looking through this, django-rainbow [1] looks simple but doesn't suit
my needs at it assumes Apache, MySQL and applications stored in
Mercurial (I use nginx or gunicorn, PostgreSQL and have my application
code hosted in git).

Looking at [2], [3] and [4], there are a lot of good ideas and reading
on subordinate services [5], one way to get this to work would be:

+- WSGI container as a principal service
    +- django framework subordinate to wsgi container
        +- django apps subordinate to django (could be any number of apps)

This would mean having a generic django charm that could be deployed
into any WSGI container (Apache, nginx, gunicorn) plus simple charms for
the apps. It's then a case of identifying what should be the
responsibility of Django and what should be the responsibility of the
apps. Django allows you to make apps agnostic from the way they are
deployed so it should be feasible.

When it comes to databases, Django uses a concept similar to the JavaEE
data source, where you define the different data sources in the
container and the apps just have to reference them by name. If you give
no reference, it uses the database called "default". So what this means
is the django charm should specify that it can have any number of "db"
relationships, the default one being called "default". It should then be
able to add new named db relationships to support applications that
require more than one data source.

The next question is how do you model the fact that a Django db
connection could accept different interfaces? Ideally, if you do
something like "juju add-relation django mysql", it should work out on
its own that it needs to ensure the correct client libraries are
installed for mysql on the django node and setup the correct
configuration parameters.

Last question (but not least!), how do you add nodes to a service
defined like this with subordinate services? Are all the subordinate
services extended to the new node as well?

Sorry about the rambling nature of this email, it's a bit of a brain
dump. I would appreciate any comment and advice on the above and in
particular what Django charm should I start with?

Thanks,

Bruno


[1] http://jujucharms.com/charms/precise/django-rainbow
[2] https://bugs.launchpad.net/charms/+bug/810581
[3] https://bugs.launchpad.net/charms/+bug/1012942
[4]
http://www.linux-support.com/cms/ubuntu-developers-michael-hall-charming-django-with-naguine/
[5] https://juju.ubuntu.com/docs/subordinate-services.html