Mailing-List: contact issues-help@aurora.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aurora.apache.org
Date: Thu, 1 Oct 2015 22:28:27 +0000 (UTC)
From: "Marco Massenzio (JIRA)" <jira@apache.org>
To: issues@aurora.apache.org
Message-ID: <JIRA.12901140.1443473157000.6540.1443738507203@Atlassian.JIRA>
In-Reply-To: <JIRA.12901140.1443473157000@Atlassian.JIRA>
References: <JIRA.12901140.1443473157000@Atlassian.JIRA>
 <JIRA.12901140.1443473157525@arcas>
Subject: [jira] [Comment Edited] (AURORA-1503) Determine how best to keep up
 with Mesos releases
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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:28 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]  repo [0] - 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?

[0] http://codetrips.com/2015/08/16/apache-mesos-leader-master-discovery-using-zookeeper-part-2/


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; 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?


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