Reusing a frontend name with 2 units causes failure

[Robin Winslow]

With 2 haproxy units, attempting to update from this services config:

- service_name: haproxy_service
  service_host: "0.0.0.0"
  service_port: 80
  service_options: [option httpchk GET /, balance leastconn, maxconn 10000]
  server_options: check inter 10000 rise 2 fall 5 maxconn 512

To this one:

- service_name: haproxy_service
  service_host: "0.0.0.0"
  service_port: 443
  crts: [DEFAULT]
  service_options: [option httpchk GET /, balance leastconn, maxconn 10000]
  server_options: check inter 10000 rise 2 fall 5 maxconn 512
- service_name: secure-redirect
  service_host: "0.0.0.0"
  service_port: 80

led to a messed up `/etc/haproxy/haproxy.cfg` (http://pastebin.ubuntu.com/23573212/) where "frontend haproxy-0-80" was declared twice, and "frontend haproxy-0-443" wasn't declared at all. Which meant that the service wasn't providing the expected HTTPS service on port 443.

With only 1 haproxy unit, everything worked as expected.

I discovered this can be avoided by simply using a new name for the new HTTPS service (e.g. "https_service"), rather than reusing "haproxy_service". However, I assume getting into the above state isn't the intended functionality.

[Adam Collard (adam-collard)]

The paste link is 404 - can you share simple steps to reproduce, e.g. a juju deploy + config

[Robin Winslow (nottrobin)]

Ah. Don't trust ubuntu pastebin. Okay, here: http://pastebin.com/7SYTsiHj

I imagine the steps to reproduce would be:

- deploy 2 haproxy units
- juju set haproxy services={the_first_config}
- wait
- juju set haproxy services={the_second_config}

But I'm afraid I don't have time to try it out right now.