[
https://issues.apache.org/jira/browse/AURORA-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14942858#comment-14942858
]
Marco Massenzio edited comment on AURORA-1503 at 10/4/15 11:42 PM:
-------------------------------------------------------------------
What [~adam-mesos] says.
Unfortunately, it's difficult to give a more specific answer - as Adam pointed
out, a {{0.24 libmesos.so}} is unlikely to work against a 0.22 Master and we
would not recommend it (it should work just fine against a 0.23).
On the specific issue of Master detection, as it happens, the 0.24 libmesos
would understand both formats[0] (complaining with a WARN about the old binary
format), but you may run into issues elsewhere, as the actual format of
{{MasterInfo}} has changed too [1]:
{code}
/**
* Describes a master. This will probably have more fields in the
* future which might be used, for example, to link a framework webui
* to a master webui.
*/
message MasterInfo {
required string id = 1;
// The IP address (only IPv4) as a packed 4-bytes integer,
// stored in network order. Deprecated, use `address.ip` instead.
required uint32 ip = 2;
// The TCP port the Master is listening on for incoming
// HTTP requests; deprecated, use `address.port` instead.
required uint32 port = 3 [default = 5050];
// In the default implementation, this will contain information
// about both the IP address, port and Master name; it should really
// not be relied upon by external tooling/frameworks and be
// considered an "internal" implementation field.
optional string pid = 4;
// The server's hostname, if available; it may be unreliable
// in environments where the DNS configuration does not resolve
// internal hostnames (eg, some public cloud providers).
// Deprecated, use `address.hostname` instead.
optional string hostname = 5;
// The running Master version, as a string; taken from the
// generated "master/version.hpp".
optional string version = 6;
---> new in Mesos 0.24.1
// The full IP address (supports both IPv4 and IPv6 formats)
// and supersedes the use of `ip`, `port` and `hostname`.
// Since Mesos 0.24.
optional Address address = 7;
}
message Address {
// May contain a hostname, IP address, or both.
optional string hostname = 1;
optional string ip = 2;
required int32 port = 3;
}
{code}
And, while the new {{Address}} field is defined as {{optional}} (hence the
(de)serialization works just fine) there may be places in the 0.24 libmesos
that may expect to find it and will fail when it's not there.
[0] https://github.com/apache/mesos/blob/master/src/master/detector.cpp#L437
[1] https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L458
was (Author: marco-mesos):
What [~adam-mesos] says.
Unfortunately, it's difficult to give a more specific answer - as Adam pointed
out, a {{0.24 libmesos.so}} is unlikely to work against a 0.22 Master and we
would not recommend it (it should work just fine against a 0.23).
On the specific issue of Master detection, as it happens, the 0.24 libmesos
would understand both formats (complaining with a WARN about the old binary
format) but you would probably run into issue as the actual format of
{{MasterInfo}} has changed too (see {{include/mesos/mesos.proto}}):
{code}
// Mesos 0.22.1
/**
* Describes a master. This will probably have more fields in the
* future which might be used, for example, to link a framework webui
* to a master webui.
*/
message MasterInfo {
required string id = 1;
required uint32 ip = 2;
required uint32 port = 3 [default = 5050];
optional string pid = 4;
optional string hostname = 5;
}
{code}
{code}
// Mesos 0.24.1
/**
* Describes a master. This will probably have more fields in the
* future which might be used, for example, to link a framework webui
* to a master webui.
*/
message MasterInfo {
required string id = 1;
// The IP address (only IPv4) as a packed 4-bytes integer,
// stored in network order. Deprecated, use `address.ip` instead.
required uint32 ip = 2;
// The TCP port the Master is listening on for incoming
// HTTP requests; deprecated, use `address.port` instead.
required uint32 port = 3 [default = 5050];
// In the default implementation, this will contain information
// about both the IP address, port and Master name; it should really
// not be relied upon by external tooling/frameworks and be
// considered an "internal" implementation field.
optional string pid = 4;
// The server's hostname, if available; it may be unreliable
// in environments where the DNS configuration does not resolve
// internal hostnames (eg, some public cloud providers).
// Deprecated, use `address.hostname` instead.
optional string hostname = 5;
// The running Master version, as a string; taken from the
// generated "master/version.hpp".
optional string version = 6;
// The full IP address (supports both IPv4 and IPv6 formats)
// and supersedes the use of `ip`, `port` and `hostname`.
// Since Mesos 0.24.
optional Address address = 7;
}
{code}
And, while the new {{Address}} field is defined as {{optional}} (hence the
(de)serialization works just fine) the code in 0.24.x expects the new fields
and will most likely fail when it does not find them:
{code}
/**
* A network address.
*/
message Address {
// May contain a hostname, IP address, or both.
optional string hostname = 1;
optional string ip = 2;
required int32 port = 3;
}
{code}
> 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)
