[
https://issues.apache.org/jira/browse/MESOS-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15323838#comment-15323838
]
Jay Guo commented on MESOS-5593:
--------------------------------
Sounds reasonable. Just wanna understand it further, are we going to have
versioned protobuf messages in {{mesos/v1/}} and unversioned protobuf message
in {{mesos/}}? I suppose all versioned messages are aggregated in unversioned
one? In this case, if we have structure change in v2, how do we maintain
compatibility in unversioned one? Simply adding the new one?
/J
> Devolve v1 operator protos before using them in Master/Agent.
> -------------------------------------------------------------
>
> Key: MESOS-5593
> URL: https://issues.apache.org/jira/browse/MESOS-5593
> Project: Mesos
> Issue Type: Improvement
> Reporter: Anand Mazumdar
> Assignee: haosdent
> Priority: Critical
> Labels: mesosphere
>
> We had adopted the following workflow for the Scheduler/Executor endpoints on
> the Master/Agent.
> - The user makes a call to the versioned endpoint with a versioned protobuf.
> e.g., {{v1::mesos::Call}}
> - We {{devolve}} the versioned protobuf into an unversioned protobuf before
> using it internally.
> {code}
> scheduler::Call call = devolve(v1Call);
> {code}
> The above approach has the advantage that the internal Mesos code only has to
> deal with unversioned protobufs. It looks like we have not been following
> this idiom for the Operator API. We should create a unversioned protobuf file
> similar to we did for the Scheduler/Executor API and then {{devolve}} the
> versioned protobufs. (e.g., mesos/master/master.proto)
> The signature of some of the operator endpoints would then change to only be
> dealing with unversioned protobufs:
> {code}
> Future<Response> Master::Http::getHealth(
> const master::Call& call,
> const Option<string>& principal,
> const ContentType& contentType) const
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
