[
https://issues.apache.org/jira/browse/MESOS-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15323870#comment-15323870
]
Jay Guo edited comment on MESOS-5593 at 6/10/16 4:55 AM:
---------------------------------------------------------
OK. However this evolving/devolving sound heavy and I wonder if we will
encounter performance issue. Another thing is that we implement Operator APIs
in different styles, some of them are implemented from scratch and others are
reusing methods/logics from previous implementation. I imagine we would have
similar problems at v2. Therefore, we end up with a very mixed and tedious
codebase.
I don't really have a clear idea on this but my point is that we want to
maintain performance while enhancing readability. For people who are not
familiar with the history, first sight of current code is quite intimidating.
Backwards compatibility is always a pain.
was (Author: guoger):
OK. However this evolving/devolving sound heavy and I wonder if we will
encounter performance issue. Another thing is that we implement Operator APIs
in different styles, some of them are implemented from scratch and others are
reusing methods/logics from previous implementation. I imagine we would have
similar problems at v2. Therefore, we end up with a very mixed and tedious
codebase.
> 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)
