AWS Load Balancer Use Case

Clint Byrum clint at ubuntu.com
Fri Oct 21 17:40:27 UTC 2011


Excerpts from Kapil Thangavelu's message of Thu Oct 20 12:12:45 -0700 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:
> > > > 
> > > > https://bugs.launchpad.net/juju/+bug/878948
> > > > 
> > > 
> > > 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.
> 

Yeah, that does seem critical for anything that allocates resources
external to the machine it is running on.



More information about the Juju mailing list