Relation's need config too

[Brandon Holtsclaw]

Getting in a bit late on this but its the exact problem I'm having with the
cs:precise/nginx-proxy as well ( it works on the surface very much like
HAProxy ) but just was adding another "me too"


-- 
Brandon Holtsclaw
Web http://brandonholtsclaw.com
Voice/SMS Tel:816-974-6106



On Wed, Jul 18, 2012 at 7:51 PM, Juan Negron <negronjl at xtremeghost.com>wrote:

> Given my recent experience with the proposed haproxy charm, I believe that
> changes like the ones Clint is proposing would have made my life a bit
> easier.
>
> +1 on the changes
>
> Thanks,
>
> Juan
>
>
>
> On Wed, Jul 18, 2012 at 5: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<https://code.launchpad.net/%7Emthaddon/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
>>
>>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20120720/a40f4b60/attachment.html>