james.westby at canonical.com
Mon Jan 16 20:44:18 UTC 2012
On Mon, 16 Jan 2012 18:15:37 -0200, Gustavo Niemeyer <gustavo at niemeyer.net> wrote:
> > 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?
Writing a single charm to handle django with any other interface that
may be provided by a charm?
I can see several problems with that:
* 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.
* It would make that generic charm the framework, rather than 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)
* 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.
* 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.
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.
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
More information about the Juju