Charm derivation

[Gustavo Niemeyer]

Hey James,

I'm CCing the juju list since your question may be relevant to other
people as well.

> Michael Nelson has written a charm to deploy a django app using
> apache/mod_wsgi etc:
>
> http://micknelson.wordpress.com/2011/11/22/a-generic-juju-charm-for-django-apps/
>
> This is great, as it just so happens that I want to deploy a django app
> using apache/mod_wsgi. However, my app also needs an AMQP broker to talk
> to, and that isn't handled in Michael's charm.
>
> I could potentially add config settings to the generic charm to work
> with AMQP, but then the next app I want to deploy will need a statsdcanonical-
> listener, or something else.
>
> Writing a generic charm to handle all these cases would be a mistake,
> but I want to re-use the logic for the django apache/mod_wsgi parts, as
> they will be  It feels like this is the correct thing to do, as long as you add some framework-level API to query whether a given relation is established. very similar across the apps.

Why do you think it'd be a mistake?

> What is the anticipated mechanism for doing this? I can't use multiple
> charms, as they have to run on the same machine and be controlled as
> one. I can't see any mechanism for inheritance in charms. Is the answer
> to use bzr for this, branching from Michael's charm and adding the AMQP
> interface, then merging improvements from Michael as needed?

No, I believe your suggestion above is the right direction to head
towards, even if we have to add some extra features in the future to
better support it. Hooks within the charm should map the relation
protocol onto metadata that makes sense for the specific framework
(django, in this case).

If you've tried that and faced issues, I'm certainly interested in
learning about them.

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

-- I'm not absolutely sure of anything.