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 <a href="http://brandonholtsclaw.com" target="_blank">http://brandonholtsclaw.com</a> Voice/SMS Tel:816-974-6106 <div class="gmail_quote">On Wed, Jul 18, 2012 at 7:51 PM, Juan Negron <<a href="mailto:negronjl@xtremeghost.com" target="_blank">negronjl@xtremeghost.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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.<div> </div><div>+1 on the changes</div><div> Thanks,<div> </div><div>Juan</div><div><div class="h5"> <div class="gmail_quote">On Wed, Jul 18, 2012 at 5:44 PM, Clint Byrum <<a href="mailto:clint@ubuntu.com" target="_blank">clint@ubuntu.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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. <a href="https://code.launchpad.net/%7Emthaddon/charms/precise/haproxy/mini-sprint-sf/+merge/114951" target="_blank">https://code.launchpad.net/~mthaddon/charms/precise/haproxy/mini-sprint-sf/+merge/114951</a> 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 <a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a> </blockquote></div> </div></div></div> -- Juju mailing list <a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a> </blockquote></div>