Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using FQNDs in service catalog to identify service names breaks configuration generation #20

Open
dantrainor opened this issue Nov 12, 2015 · 0 comments

Comments

@dantrainor
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant