You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Anand Mazumdar (JIRA)" <ji...@apache.org> on 2016/08/22 19:42:20 UTC

[jira] [Commented] (MESOS-6016) Expose the unversioned Call and Event Scheduler/Executor Protobufs.

    [ https://issues.apache.org/jira/browse/MESOS-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15431478#comment-15431478 ] 

Anand Mazumdar commented on MESOS-6016:
---------------------------------------

{noformat}
commit e3143e756fafe343a79cadb10b587fad0e5904d5
Author: Anand Mazumdar <an...@apache.org>
Date:   Mon Aug 22 11:15:26 2016 -0700

    Exposed unversioned scheduler/executor protos in Mesos JAR.

    This change exposes the unversioned scheduler/executor protos
    in the Mesos JAR. We already used to expose the unversioned
    Mesos protos. This is useful for migrating schedulers to use
    the new v1 API via the scheduler shim. Otherwise, they would
    need to create their own copy of these protobufs even for vetting
    the new API via the shim. Note that this only partially resolves
    MESOS-6016 and that we would need to tackle the unversioned protobuf
    deprecation later eventually.

    Review: https://reviews.apache.org/r/51130/
{noformat}

> Expose the unversioned Call and Event Scheduler/Executor Protobufs.
> -------------------------------------------------------------------
>
>                 Key: MESOS-6016
>                 URL: https://issues.apache.org/jira/browse/MESOS-6016
>             Project: Mesos
>          Issue Type: Task
>            Reporter: Anand Mazumdar
>              Labels: mesos
>
> Currently, we don't expose the un-versioned (v0) {{Call}}/{{Event}} scheduler/executor protobufs externally to framework authors. This is a bit disjoint since we already expose the unversioned Mesos protos. The reasoning for not doing so earlier was that Mesos would use the v0 protobufs as an alternative to having separate internal protobufs internally. 
> However, that is not going to work. Eventually, when we introduce a backward incompatible change in {{v1}} protobufs, we would create new {{v2}} protobufs. But, we would need to ensure that {{v2}} protobufs can somehow be translated to {{v0}} without breaking existing users. That's a pretty hard thing to do! In the interim, to help framework authors migrate their frameworks (they might be storing old protobufs in ZK/other reliable storage) , we should expose the v0 scheduler/executor protobufs too and create another internal translation layer for Mesos.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)