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

Marathon app ID => Consul service name mapping #36

Open
JayH5 opened this issue Oct 5, 2015 · 3 comments
Open

Marathon app ID => Consul service name mapping #36

JayH5 opened this issue Oct 5, 2015 · 3 comments

Comments

@JayH5
Copy link
Contributor

JayH5 commented Oct 5, 2015

The way we map Marathon app IDs to Consul service names at the moment is less than ideal. What we currently do is something like...

  • Given a Marathon app with the ID /my-group/my-app...
  • Trim the leading / => my-group/my-app
  • Replace the /s (as they are not DNS-compatible) with -s => my-group-my-app
  • Check if any other Marathon app names map to the same thing and throw an exception if so
  • Create the Consul service my-group-my-app and add the tag consular-app-id=/my-group/my-app so that the service can be mapped back to the app.

The problem is that it's quite easy for multiple Marathon app IDs to map to the same Consul service name. For example, /testing/my-webapp and /testing-my-webapp both would map to testing-my-webapp. Consular won't allow this to be a valid state but all it can really do is crash which is not great 😢

@JayH5
Copy link
Contributor Author

JayH5 commented Oct 5, 2015

Alternative design 1

Make the user specify the service name with an app label

  • Given the app with ID /my-group/my-app...
  • Have the user add a Consul service name as a label for the Marathon app. Something like a label with the name consular-service-name and the value my-app-service.
  • Use the label value for the service name. If there is no label, default to the app ID without the leading /*.
  • Check if there are conflicting service names, spit out a (very firm) warning or throw an exception if so.
  • Create the Consul service my-app-service and add the tag consular-app-id=/my-group/my-app so that the service can be mapped back to the app.

*We trim the leading / so that in the basic use case where the user is not using Marathon app groups, the apps can map to names that can be looked up via DNS. Other /s will remain which is not a problem when saving the app to Consul but will make it impossible to look up the service via DNS.

@JayH5
Copy link
Contributor Author

JayH5 commented Oct 5, 2015

Alternative design 2

Base32 encoded app IDs

  • Given the app with ID /my-group/my-app...
  • Encode the app ID using Base32 => F5WXSLLHOJXXK4BPNV4S2YLQOA======
  • Trim the padding => F5WXSLLHOJXXK4BPNV4S2YLQOA
  • Create the Consul service F5WXSLLHOJXXK4BPNV4S2YLQOA and add the tag consular-app-id=/my-group/my-app. The service name can be decoded back to the app ID but this tag makes it easier for a human to do so as well.

Advantage: 1-to-1 app ID to service name mapping. No conflicts possible.

Disadvantage: Verbose and not very friendly app names.

@JayH5
Copy link
Contributor Author

JayH5 commented Oct 5, 2015

Alternative design 3

Provide a choice for how to map app IDs to service names

  • Add a command line option, say, --mapping with possible values hyphens, labels, or base32 for each of the mappings I've come up with above.
  • Requires implementing all of the designs. 😕

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