Relation's need config too

[Gustavo Niemeyer]

Hi Clint,

We've also conceptualized (but not designed, you went further than we
did) relation settings in one of the first development sprints, in
Brazil, and funny enough the example we came up with was precisely one
of a load balancer (haproxy in our brainstorm), even though we were
thinking about URL paths rather than hostnames, but it was going in
the same direction of what you described.

I don't know about details yet, as we have to think how interfaces
match each other, who owns the data, how upgrades work, etc, but +1 on
something along these lines as well for post 12.10.


On Wed, Jul 18, 2012 at 9:44 PM, Clint Byrum <clint at ubuntu.com> wrote:
> I"ve run into this problem a few times, and I think there's a hole in
> the current model that needs filling.
>
> Recently Juan Negron and Tom Haddon submitted a really awesome set of
> enhancements for the haproxy charm.
>
> https://code.launchpad.net/~mthaddon/charms/precise/haproxy/mini-sprint-sf/+merge/114951
>
> You can see there a lot of it was some nice abstraction for juju commands
> which I think belongs in its own package. But thats not what I'm writing
> about.
>
> Tom and Juan felt that there needed to be a way to assign units of
> a backend web service to servics, which were created by dumping raw
> haproxy service configs into a config option.
>
> They're right! But I have some deep concerns about the proposed method.
>
> The merge proposal wants to add a parameter for the "provides" side of
> the http interface which uniquely identifies which endpoint service this
> web server wants to belong to. Right now most web services do something
> like this in an http interface 'joined' hook:
>
> relation-set hostname=$(unit-get private-address) port=$(config-get myport)
>
> Then load balancers can just add this hostname/port combo to their
> backend list to spray content to.
>
> This presents issues though, because now we can't do multi-site on either
> the load balancer *or* the backend. This is what the Host: header is
> meant for.
>
> The proposal has us passing in a yaml list of services to define:
>
>   - service_name: website1
>     service_host: "website1.foo.bar"
>     service_port: 80
>     service_options: [balance leastconn]
>     server_options: maxconn 100
>   - service_name: website2
>     service_host: "website2.foo.bar"
>     service_port: 80
>     service_options: [balance leastconn]
>     server_options: maxconn 100
>
> Then each backend service which wants to be able to be bound to a specific
> frontend would change their joined to do:
>
> relation-set hostname=$(unit-get private-address) \
>              port=$(config-get myport) \
>              service_name=$(config-get my-service-name)
>
> This feels *very* limiting. In order to close the loop we have to set
> configs on both ends of a relationship, and the configs we have to set
> are extremely complicated and error prone.
>
> I think there's a need for relations to have config items, as this would
> solve the problem far more elegantly.
>
> I'd propose that it work like this:
>
> * metadata.yaml:
>
> requires:
>   backends:
>     interface: http
>     options:
>         endpoint-host:
>             type: string
>             description: Host to tie this traffic to.
>         endpoint-port:
>             type: int
>             default: 80
>             description: Port to tie this traffic to.
>
> * relation-config-get
>
> A new command, like config-get, but works in relation context only to
> pick these up. Changes to relation config settings would fire the same
> relation-changed hooks as changes on the units fire.
>
> * juju add-relation , juju set-relation
>
> Commands to set values for these per-relation. So
>
> juju add-relation wp1 loadbalancer endpoint-host="website1.foo.bar"
>
> For the simple case (one frontend, one backend) nothing would then change,
> but this would also allow this:
>
> juju add-relation wp2 loadbalancer endpoint-host="website2.foo.bar"
>
> So now haproxy has become multi-site, which is crucial, as load balancing
> is really quite a low-impact duty and one m1.small can handle thousands
> of requests per second.
>
> But what about wordpress? It could be multi-site too. So I think we
> should also enable this:
>
> juju add-relation wp1 loadbalancer endpoint-host="website1.foo.bar"
> juju add-relation wp1 loadbalancer endpoint-host="website2.foo.bar"
>
> Note that this is the same two services related, but with two different
> relationships.  This would allow both haproxy and wordpress to be
> multi-site.
>
> This is not the only case of this. There are quite a few others. For
> instance one might want to have multiple services accessing the same
> mysql db. This makes more sense doing at relation time, and not with
> config settings. The way it works now:
>
> juju deploy mysql mydb
> juju deploy service1 --set store-db=foo
> juju deploy service2 --set service-db=foo
> juju add-relation mydb service1
> juju add-relation mydb service2
>
> Versus
>
> juju deploy mysql mydb
> juju deploy service1
> juju deploy service2
> juju add-relation mydb service1 db=foo
> juju add-relation mydb service2 db=foo
>
> Thoughts?
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju



-- 
gustavo @ http://niemeyer.net