[jira] [Commented] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.
[
https://issues.apache.org/jira/browse/MESOS-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15326012#comment-15326012
]
haosdent commented on MESOS-5593:
-
Sure, I added you as reviewers as well ;-)
> 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
> Fix For: 1.0.0
>
>
> 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 Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.
[
https://issues.apache.org/jira/browse/MESOS-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15323896#comment-15323896
]
Jay Guo commented on MESOS-5593:
OK.
BTW, do you guys do other forms of scale tests other than concurrency test in
MESOS-5222?
> 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 Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.
[
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:
[~haosd...@gmail.com] 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 Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.
[
https://issues.apache.org/jira/browse/MESOS-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15323888#comment-15323888
]
Anand Mazumdar commented on MESOS-5593:
---
Thanks [~haosd...@gmail.com] :-)
> 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 Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.
[
https://issues.apache.org/jira/browse/MESOS-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15323881#comment-15323881
]
Anand Mazumdar commented on MESOS-5593:
---
The main problem with some of the past methods is that they did not have a
corresponding protobuf message/schema or the schema is not analogous to the new
API. Hopefully, this won't be the case when we move to {{v2}}.
Let's take an example:
For {{v2}}, a user would hit the {{/api/v2}} endpoint, we would {{devolve}} the
request to a {{mesos::master}} unversioned protobuf and use it internally.
While sending the response back to the client, it would be {{evolve}}'d back to
{{v2}}. There should not be any noticeable performance degradations (at least
we did not observe them while doing scale testing as part of MESOS-5222.
Hope this helps.
> 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 Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.
[
https://issues.apache.org/jira/browse/MESOS-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15323870#comment-15323870
]
Jay Guo commented on MESOS-5593:
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 Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.
[
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 Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.
[
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 Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.
[
https://issues.apache.org/jira/browse/MESOS-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15323780#comment-15323780
]
haosdent commented on MESOS-5593:
-
I think I could help on this.
> 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
>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 Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5593) Devolve v1 operator protos before using them in Master/Agent.
[
https://issues.apache.org/jira/browse/MESOS-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15323764#comment-15323764
]
Anand Mazumdar commented on MESOS-5593:
---
cc: [~haosd...@gmail.com] [~guoger] Would one of you like to help on this
issue?
> 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
>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 Master::Http::getHealth(
> const master::Call& call,
> const Option& principal,
> const ContentType& contentType) const
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
