Does juju support 'named' interfaces?

[Clint Byrum]

Excerpts from Sidnei da Silva's message of 2012-06-26 05:55:46 -0700:
> On Tue, Jun 26, 2012 at 3:41 AM, Clint Byrum <clint at ubuntu.com> wrote:
> > I think this shouldn't be too challenging:
> >
> > Some stipulations:
> > * both requires and provides can be satisfied/utilized multiple times.
> > * each established relationship has an ID. You will see it in the
> >  *-relation-* hooks as $JUJU_RELATION_ID. They can also be enumerated
> >  with `relation-ids`.
> > * Each unit of each service related to you will cause relation-joined
> >  and relation-changed hooks with a different $JUJU_UNIT_NAME.
> > * One can have multiple relations of the same interface type
> >
> > Given that, I'd do this with the current pgsql charm:
> >
> > * Require a separate relation name for the "mapping" database.
> > * Make the number of shards configurable. Default to -1 which means
> >  "1 per shard db server" shard names are just shard#
> > * mapping-relation-changed: assign all unassigned shards in all available
> >  shard dbs.
> > * shard-relation-changed: record shard db target in a list of available
> >  shard dbs.
> > * Use $JUJU_RELATION_ID+$JUJU_UNIT_NAME to uniquely name them.
> > * re-run mapping-relation-changed
> > * shard-relation-departed/broken: shard is funneled to an unused pool
> >  if possible, or somehow flagged as "dead" or "orphaned"
> > * config-changed basically just re-runs mapping-relation-changed
> 
> I think what's missing here is a way to identify which shard unit
> contains the data for a specific shard, by naming it explicitly. I
> like Gustavo's suggestion to make the shard name a property of the
> interface.
> 

I'm not sure I understand how this is going to work.

So you're going to modify pgsql to have some kind of 'pgsql-shards'
interface, which communicates the same stuff as pgsql, but also
'shard-name'? I'd suggest that become a more generic 'pgsql-shared'
that models the mysql-shared interface.

And then you'll decide somehow which shard goes where, and relate multiple
times. So..

juju deploy pgsql shard-db-A
juju deploy pgsql shard-db-B
juju deploy myappserver
juju add-relation myappserver shard-db-A
juju add-relation myappserver shard-db-B

How then do you say that shard1 goes to shard-db-A. There may be multiple
units of myappserver, so you can't just pick, you need to coordinate
that. You could dump your original config file in, with service names in
place of host names:

juju set myappserver "shardmap=`cat shards.yaml`"

But now you have to rely on humans not to screw that up.. and the whole
thing is far less independent and more error prone. Seems a bit sad
not to take advantage of the scale-out nature of juju and trust it to
automate the allocation and assignment of shards.

On a side note, perhaps postgres-xc would be better still?