bail out if reregistered version != registered version

[spacejam]

Because mesos-go bindings are version-specific, and we'd like to support down to version 0.22 up through 0.24, if we reregister and the master version has increased then we should bail out so that a wrapper script can start with the proper mesos-go version. This is a race condition, as the master may have been upgraded after the detector wrapper ran but before the registered call completed, but the window is small.

[jdef]

That's interesting. Do you know of other frameworks that use pure language bindings that do this?

On Mon, Sep 21, 2015 at 4:34 PM, Tyler Neely notifications@github.com wrote:

Because mesos-go bindings are version-specific, and we'd like to support down to version 0.22, if we reregister and the master version has increased then we should bail out so that a wrapper script can start with the proper mesos-go version. This is a race condition, as the master may have been upgraded after the detector wrapper ran but before the registered call completed, but the window is small.

— Reply to this email directly or view it on GitHub https://github.com/mesosphere/etcd-mesos/issues/60.

[spacejam]

@jdef no idea, but every build of this driver has a certain range of compatible master versions, and if we detect that we've stepped outside of that range, then we have stepped out of our known safe operating conditions and may be essentially dropping messages from the master or failing to send valid ones to it.

[pires]

With the release of Mesos 1.0 and v1 API becoming stable, I believe this no longer makes sense. Therefore, I strongly suggest to drop this in favor of supporting Mesos 1.x and the v1 API in the short term.

/cc @jdef

[jdef]

why does this no longer make sense w/ respect to the availability of the v1 API? mesos behavior can change from release to release. the core team tries very hard to not break compat across releases, but sometimes breakage is unavoidable