AWS Load Balancer Use Case

Luis Arias kaaloo at gmail.com
Mon Oct 24 12:38:16 UTC 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