gustavo.niemeyer at canonical.com
Mon Jan 16 21:02:24 UTC 2012
> 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
> * 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
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.
-- I'm not absolutely sure of anything.
More information about the Juju