Using the default HAPROXY_MODE of 'consul', I believe I'm seeing what appears to be breakage when parsing for .Name to configure backend servers.
I'm using marathon-consul to get Marathon data in to consul. It works great and I can curl GET query consul for this Marathon data all day long.
An excerpt from haproxy.cfg:
backend api.184.integration.project.platform.domain_backend
backend database.184.integration.project.platform.domain_backend
backend frontend.184.integration.project.platform.domain_backend
backend project-api_backend
server mesos-master01.infrastructure.domain 172.32.x.x:31132
backend project-database_backend
server mesos-master01.infrastructure.domain 172.32.x.x:32861
backend project-frontend_backend
server mesos-master01.infrastructure.domain 172.32.x.x:32072
I'm using SERVICE_NAME to name the service (http://gliderlabs.com/registrator/latest/user/services/) and had been wondering if this is what broke the configuration, until I did a test using SERVICE_NAME but using a more simple name, one which did not represent a FQDN.
If I don't use SERVICE_NAME, or if I don't name the service to contain periods, my backends are then assigned a server as expected.
Using the default HAPROXY_MODE of 'consul', I believe I'm seeing what appears to be breakage when parsing for .Name to configure backend servers.
I'm using marathon-consul to get Marathon data in to consul. It works great and I can curl GET query consul for this Marathon data all day long.
An excerpt from haproxy.cfg:
I'm using SERVICE_NAME to name the service (http://gliderlabs.com/registrator/latest/user/services/) and had been wondering if this is what broke the configuration, until I did a test using SERVICE_NAME but using a more simple name, one which did not represent a FQDN.
If I don't use SERVICE_NAME, or if I don't name the service to contain periods, my backends are then assigned a
serveras expected.