Does juju support 'named' interfaces?

[Sidnei da Silva]

On Tue, Jun 26, 2012 at 1:27 PM, Clint Byrum <clint at ubuntu.com> wrote:
> 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.

I'm very open to suggestions on how to improve this. Keep in mind
we're talking about an already existing application which isn't built
for automatic scale-out on the database side, and where there's
existing data that has been manually assigned to specific hosts.

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

Possibly yes.

My immediate goal is to incrementally introduce juju on top of that,
by (as Robert proposed) having 'fake' charms that only provide the
metadata about how to connect to the existing shards, and scaling out
the things that are currently built to be scaled out with real charms,
and maybe once that's solved we can look at something like
postgres-xc.

-- 
Sidnei

Make the most of Ubuntu with Ubuntu One
http://one.ubuntu.com