AWS Load Balancer Use Case

Kapil Thangavelu kapil.thangavelu at
Thu Oct 20 19:12:45 UTC 2011

Excerpts from Clint Byrum's message of Thu Oct 20 14:51:00 -0400 2011:
> Excerpts from Kapil Thangavelu's message of Thu Oct 20 10:47:23 -0700 2011:
> > Excerpts from Clint Byrum's message of Thu Oct 20 12:22:51 -0400 2011:
> > > The haproxy charm could probably use some refactoring (its about the third
> > > charm I ever wrote, maybe the 5th charm ever published. ;) so that these
> > > were safer operations (relating two things to haproxy at once results
> > > in a race condition)
> > 
> > Just adding a few minors.
> > 
> > hooks are execute serially on a unit, so there is no race on haproxy with 
> > concurrent changes.
> Indeed, however, the haproxy can only listen on port 80 for one set of
> backing servers without the help of HTTP Host header checking. We have no
> way of knowing what Host header goes where with the current simple 'http'
> interface used. There is a 'url' interface that needs to be implemented
> whereby a backing service can feed what host and sub-path it expects to
> be hosted under.
> So its a race because the last service that gets related ends up being
> the only one that gets served by haproxy.

ic. thanks for clarifying.

> > 
> > > 
> > > But anyway, thats how I would do it.
> > > 
> > > To address how to relate to ELB/RDS, we need something like a virtual
> > > charm which runs its hooks somewhere, but doesn't actually take up
> > > resources in the juju environment itself, and can return different values
> > > for private-address and public-address when related to. That would be
> > > useful for not only AWS things like ELB and RDS, but also for things
> > > like domain registrar DNS services and other business units within the
> > > same organization.
> > > 
> > > I think this may be a duplicate but I opened this bug because I know
> > > we've been talking about the concept for a while but haven't actually
> > > done anything about the concept:
> > > 
> > >
> > > 
> > 
> > As i see it, ELB is effective just another charm without a service backing it, 
> > the hooks for it directly interact with ELB via the aws api, and its service 
> > config takes aws credentials.
> > 
> Agreed. The details that are important is that this charm needs to be
> deployed somewhere regardless of resources available (machine 0 and its
> soon to be realized contemporaries maybe) and allow for overriding of
> private-address and public-address, so that it can implement identical
> interfaces to regular charms. For instance, just like haproxy, it would
> provide an http interface so you could relate that to a monitoring
> service.

ic, good points. its useful to note that the private-address exposed to the 
related services is overridable with relation-set, the value present in the 
relation is just a default. The public address as exposed by status would need 
manipulation. introducing an equivalent unit-set to unit-get might be adequate, 
with support for just a few keys going to zk, the rest going to local disk 
(akin to the faceter usage). The invocation of stop hooks here is critical as
the elb is creating instances outside of the purview of the environment, which
would persist post environment-destruction.

More information about the Juju mailing list