[
https://issues.apache.org/jira/browse/AURORA-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940522#comment-14940522
]
Marco Massenzio edited comment on AURORA-1503 at 10/1/15 10:22 PM:
-------------------------------------------------------------------
Folks - I work on the Mesos project and was actually the person implementing
the switch-over that occurred over the 0.23-to-0.24 changes in ZK
{{MasterInfo}} serialization format.
To be honest, we did this to be more friendly to non-C++ developers, who no
longer would need to depend on Protobuf and libmesos.so for their framework;
obviously sorry we broke Aurora in the process.
I'd be happy to help out implement a patch that essentially works with both
formats, as that would be probably a relatively minor change in your existing
code's logic.
An example of how to do this (in Python) is in my
[zk-mesos|http://github.com/massenz/zk-mesos] - any other language would be a
similarly trivial change: if my understanding is correct, as Aurora is in Java
(BTW - your http://aurora.apache.org/documentation/CONTRIBUTING.md goes 404) I
would be happy to provide a patch that you guys can then integrate in
accordance with your practices.
As an outline - pre-0.24, the format of the znode data was {{infoNNNNN}} and in
binary Protobuf format; afterwards, it's named {{json.infoNNNNN}} - so one can
either adopt the "naive" strategy (try to deserialize one way; if it fails, try
the other) or "look-ahead" and, based on the naming of the nodes, pick the
correct strategy.
Comments?
was (Author: marco-mesos):
Folks - I work on the Mesos project and was actually the person implementing
the switch-over that occurred over the 0.23-to-0.24 changes in ZK
{{MasterInfo}} serialization format.
To be honest, we did this to be more friendly to non-C++ developers, who no
longer would need to depend on Protobuf and libmesos.so for their framework.
I'd be happy to help out implement a patch that essentially works with both
formats, as that would be probably a relatively minor change in your existing
code's logic.
An example of how to do this (in Python) is in my
[zk-mesos|http://github.com/massenz/zk-mesos] - any other language would be a
similarly trivial change: if my understanding is correct, as Aurora is in Java
(BTW - your http://aurora.apache.org/documentation/CONTRIBUTING.md goes 404) I
would be happy to provide a patch that you guys can then integrate in
accordance with your practices.
As an outline - pre-0.24, the format of the znode data was {{infoNNNNN}} and in
binary Protobuf format; afterwards, it's named {{json.infoNNNNN}} - so you one
can either adopt the "naive" strategy (try to deserialize one way; if it fails,
try the other) or "look-ahead" and, based on the naming of the nodes, pick the
correct strategy.
Comments?
> Determine how best to keep up with Mesos releases
> -------------------------------------------------
>
> Key: AURORA-1503
> URL: https://issues.apache.org/jira/browse/AURORA-1503
> Project: Aurora
> Issue Type: Task
> Reporter: Zameer Manji
> Assignee: Zameer Manji
>
> Aurora 0.9.0 was released with a dependency on Mesos 0.22. The current
> release is Mesos 0.24. There was a change with how data was published into
> the Mesos ZK node in Mesos 0.23 (Protobuf to JSON) meaning that frameworks
> that are linked against 0.22 will get a libmesos error when using the 0.24
> library.
> The task is to determine what is the best way forward in scenarios like this.
> Possible options include:
> * Release 0.9.x with a newer mesos dependency
> * Cut a new release from master that depends on 0.24
> Problems include backwards/forwards compatibility. For example if we release
> 0.9.1 with a dependency on Mesos 0.24 will Aurora still work against a Mesos
> Master that runs 0.22?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
