Charm derivation

[Gustavo Niemeyer]

> Writing a single charm to handle django with any other interface that
> may be provided by a charm?

I'm pretty sure many interfaces won't be relevant for a django charm.

I don't think all interfaces will be interesting for a django charm.

>  * It would be very unwieldly: hard to read and write
>  * It would be very hard to test
>  * It would have to support every conceivable interface, including
>    non-public interfaces, for instance if I have two django apps that
>    have to communicate through some specific interface I would
>    immediately be unable to use this mega-charm.
>  * The mapping from interface to settings.py attribute isn't
>    standardised for the most part, you could make use of an AMQP
>    interface expecting the credentials to be specified in any
>    attributes that you want.

Yes, it's a significant amount of work to support a completely generic
Django charm.

>  * It would make that generic charm the framework, rather than juju.

Almost. It'd make the generic charm a framework that builds on juju.

>  * I don't think it would be possible to make use of the charm twice in
>    the same environemnt with different configuration (again the example
>    of two django apps that have to communicate)

That's true. Maybe there's a place for dynamic relations somewhere.
Will keep that as background thinking for now.

>  * It would be a nightmare to maintain in lp:charms as you would have
>    to agree to every addition that someone wants and keep all of them
>    in mind when making changes.
>  * Add in changing interfaces and you amplify each of these issues.

These sound like normal requirements for any relevant charm regardless?

>  * You would have to put all of this plumbing in place for each charm
>    that targets a frameworks (django, zope, pyramid, ruby on rails,
>    cake PHP, etc., etc.

Yep! I'm actually pretty excited about that. It'll be awesome to make
the foundations of juju comfortably consumed by these frameworks.

> To take a step back, what I want to be able to say is:
>
>  * I have a django app
>  * It also makes use of these interfaces, which I wish to be provided
>    by these particular charms.

Sure.. You want to create a charm specifically to a given django
application, and that's totally reasonable as well. In this case, you
can use Michael's charm merely as a guideline for your own charm and
then deploy your charm as a full-fledged application with its own
charm name and all. Great as well.

> Most of that would be provided by stacks, remembering the specific
> charms, and the config settings, but it still needs to know how to map
> the interfaces to django settings.
>
> For each interface the relation attributes are well defined, so all I
> would need to specify is the attributes to map these to (perhaps with
> defaults for e.g. db, which is standardised for standard uses in
> django.) The rest could then be handled by generic code.
>
> Yes, this can all be done in a single charm, but I don't think it should
> be.

Both seem ok to me. In one case you have a charm for a given app. In
the other you have a generic framework that enables people to not
fiddle with juju details at all, pretty much like a PaaS.

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.