[
https://issues.apache.org/jira/browse/MESOS-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15323839#comment-15323839
]
haosdent commented on MESOS-5593:
---------------------------------
I think we always could change the unversioned protobuf message and make sure
it could convert to v1 or v2 more easily because it is only used internally.
But change v1 or v2 should be difficult because it have been public.
{quote}
Simply adding the new one?
{quote}
I think just need add a more evolve/devolve method.
> 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)
