[jira] [Comment Edited] (AURORA-1503) Determine how best to keep up with Mesos releases

["Marco Massenzio (JIRA)" <ji...@apache.org>]

    [ 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)