AWS Load Balancer Use Case

[Clint Byrum]

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.

> 
> > 
> > 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.