Does juju support 'named' interfaces?
robert at ubuntu.com
Tue Jun 26 01:33:36 UTC 2012
On Tue, Jun 26, 2012 at 1:05 PM, Sidnei da Silva
<sidnei.da.silva at canonical.com> wrote:
> Hi there,
> For Ubuntu One (and, I assume, for a couple other services out there),
> we have named database shards that users are assigned to according to
> a mapping specified by yet-another database.
> So, in order to connect a service to those sharded databases, I need
> to require not just a single pgsql interface, but a finite set of
> 'named' pgsql instances which will be assigned to each shard.
> So to be more specific, when I do:
> juju add-relation my-app my-deployed-shard0
> ...where 'my-app' requires multiple pgsql backends (shard[0-N]) and
> 'my-deployed-shard0' would *have* to be used as 'shard0' by 'my-app',
> how does one structure this?
> I can see someone working around this by forking the pgsql charm as
> 'pgsql-shard[0-N]' and each of those charms only providing the
> specific interface, and having the app require 'pgsql-shard[0-N]'
> instead of a generic 'pgsql' charm, but clearly this would cause an
> unnecessary interface explosion.
So there are two things here. Firstly, you don't need to fork a charm
to name it differently, just supply a name. (The tutorial now shows
this since I had the same confusion recently :P)).
juju deploy charm nametocallitthistime.
So you could do
juju deploy charm pgsql shard0
juju deploy charm pgsql shard1
juju deploy charm pgsql shardN
Then add-relation from those shards to whatever you have managing
shards and let it decide where to map etc. Scaling up would be a
matter of deploying another shard, adding a relation saying its a
shard, and the rest should be automatic.
The other thing is units. Units represent horizontally scaling
components that are homogeneous. So you could also model this as
juju add-unit -n 3 pgsql
to add three shards, and use the units as the thing you fan out
amongst. I'd be inclined to try this way first, TBH.
That said,running persistent storage within juju is unclear to me
today, given the lack of volume and snapshotting integration. I'd be
strongly inclined to inject the data about your shards into juju using
fake charms that just contain the metadata (through config.yaml files)
about the real shards.
More information about the Juju