A charm's "role"?

[Mark Mims]

so, please take a look at the readme for the current hadoop charm

    http://jujucharms.com/charms/precise/hadoop

Several quite different services can be started from a single charm.
Instead of having seperate `hadoop-master` and `hadoop-slave` charms,
we have a single `hadoop` charm from which we can deploy:

    juju deploy hadoop hadoop-master
    juju deploy hadoop -n20 hadoop-slave
    juju add-relation hadoop-master:namenode hadoop-slave:datanode
    juju add-relation hadoop-master:jobtracker hadoop-slave:tasktracker

and the different services take on different roles based on the
interfaces that get activated.  This is a simple example, but we have
other variations of roles across services for a single charm...  take a
look at complex, multiregion hbase or opentsdb stacks for instance and
the power of this becomes clear.

While the roles above are determined solely by the interfaces at
relation time, they can also be determined by config... and potentially
changed throughout the lifetime of a service.

The possible "roles" that a charm can support are dynamic and
hard(impossible?) to determine statically.  We've been trying to keep
them captured cleanly in each charm's README... and I think doing a
decent job of this.

As we dig deeper into charm development, we're seeing more and more
charms do this (reviewing the latest version of the mongodb charm
triggered this email).  We'll putting this forth as a (possibly
advanced) best practice for charming.  I'll add a feature request for
the next gen of juju to add an additional dimension to this so that a
charm can act in both primary _and_ subordinate roles.

This seems like an emergent form of charm specialization that we've
discussed before as "charm inheritance" or something like that on this
list, but I wanted to get this out for discussion to make sure we're:
  a.) not blurring of confusing concepts irrecoverably
      this should be explicitly thought through at the framework
      level
  b.) covering this in future development
  c.) spawning other ideas around this... it's pretty rich and
      powerful

Thoughts?


-- 
Mark Mims, Ph.D.
Ubuntu Server Team
Canonical Ltd.
mark.mims at canonical.com
+1(512)981-6467