[
https://issues.apache.org/jira/browse/MESOS-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15323895#comment-15323895
]
Jay Guo commented on MESOS-5593:
--------------------------------
[[email protected]] let me know when you are done with internal master.proto
and I will rebase accordingly.
> 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)