AWS Load Balancer Use Case

Kapil Thangavelu kapil.thangavelu at canonical.com
Mon Oct 24 16:18:10 UTC 2011


So i'd try to see what you can achieve just within the charm interface, which is 
juju's public interface. 

If you think there are things missing and want to contribute to the core, thats 
great as well. Its probably a good idea in such a case to come meet the 
developers on the freenode irc channel #juju so we can help you figure out what 
the best way to do something is.

So back to an ELB charm

 - The fact that elb charm is external doesn't need to be noted in the metadata 
   or config.
 - Placement is a deploy time decision not a property of the charm, you can
   deploy it with --policy=local if you want to avoid an extra machine 
   allocation for the elb service.
 
I'd start off with something that uses your favorite language's ec2 library and 

 on install hook
    installs ec2 library and language deps

 on ?-relation-joined  hook
    create a elb for the related service it doesn't exist
    add the remote unit to the elb

 on ?-relation-depart  hook
    remove the remove unit from the elb

 on ?-relation-changed  hook
    double check the unit's elb entry against current port/host, might not
    be needed in a first cut.

 on stop hook
    destroy the elb.

for the config metadata the ec2 credentials needed to setup an elb.

i'd start with just a elb relation for the interface 'http' to get started.

I should warn that we currently have a bug that prevents the stop hook from 
being called, so you'll need to be careful to use the aws console to 
shutdown the elb and its instances, as it being created outside of the 
environment, and won't be destroyed as part of destroy-environment.

cheers,

Kapil

Excerpts from Luis Arias's message of Mon Oct 24 08:38:16 -0400 2011:
> Hi all,
> 
> Thank you so much for the bug (feature) report and discussion!  I
> spent some time this morning looking at the juju codebase to try to
> understand how to implement an external service.  I would like to be
> able to use this feature and would like to help.  I don't know what I
> would be allowed to change though.  For instance, would the fact that
> an ELB charm relies on an external service be something new in the
> charm's metadata or would it be better to place that information in
> the charm's config ?  Seems to me it would be nice to have it in the
> metadata but maybe this data structure is not meant to be changed too
> often.  I was thinking of updating the place_unit function in
> placement.py to force placement_policy to local policy in the case of
> an external service, but I don't quite see how to get the charm
> metadata or config from the unit_state.  This is probably somewhat
> over my head but maybe I could help out with some mentoring and I can
> always test.  I'm certainly glad to have learned a bit more about
> juju's magic already! :)
> 
> Luis
> 
> On Fri, Oct 21, 2011 at 7:40 PM, Clint Byrum <clint at ubuntu.com> wrote:
> > 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.
> >
> > --
> > Juju mailing list
> > Juju at lists.ubuntu.com
> > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
> >
> 



More information about the Juju mailing list