Zookeeper-aware mode for finding marathon uri

[timvaillancourt]

Hey guys,

I would like to start a discussion around functionality to get the Marathon URI from Zookeeper instead of an http:// URL. This would allow for much more dynamic deployments as go-marathon would essentially 'discover' where Marathon is instead of requiring a static http:// URI to connect to that could change. You could use a load balancer as a workaround but I think using ZK is better if it's already there.

I would be happy to implement this in a PR/branch given some agreement from anyone insteresteds on how to achieve it.

Thanks!

[timoreimann]

Hi @timvaillancourt. Thanks for bringing your proposal forward.

Just to be sure I understand your use case properly, may I ask if you happen to have a concrete need for the kind of service discoverability you outlined? And are you thinking of retrieving the Marathon URLs from Zookeeper only during the initialization phase, or possibly in an updating fashion during runtime as well?

Personally, I don't operate in an environment where the Marathon URLs change frequently enough to warrant an integration with Zookeeper, but that's just me and doesn't mean I am opposing the idea. My biggest concern probably is that we'll likely need to integrate some ZK client library and thereby have to enlarge our dependency surface, which is something that should be weighted against the potential benefit of the feature. It looks to me though that we could vendor such a client library as we seem to be in the kind of special territory where vendoring is allowed for libraries.

Those are my very initial two cents. Happy to continue discussing once the requirements are more clear.

[timvaillancourt]

Hi @timoreimann, I would probably start simple and only grab the URIs during the init phase of go-marathon if an list of Zookeeper URIs was provided. There is probably a pretty reliable way to gather the list of available Marathon instances from whichever path Marathon is using in Zookeeper.

This would add one dependency, yes. https://github.com/samuel/go-zookeeper seems to be the de facto driver for ZK.

[timoreimann]

@timvaillancourt a downside from reusing the ZK node that Marathon is already using is that you couple go-marathon's fate to Marathon's as far as ZK discoverability is concerned. That is, if Marathon is ever going to change the ZK backend structure, go-marathon will be affected too. Chances are this won't show up in any change log or README file as it can be considered an implementation detail of Marathon.

Maybe the ZK format that Marathon employs is simple enough so that users can choose between relying on Marathon's ZK data and managing dedicated ZK nodes on their own. That way, it's going to be up to each user to decide how much risk they are willing to take in return for more convenience.