Mailing-List: contact user-help@mesos.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@mesos.apache.org
MIME-Version: 1.0
In-Reply-To: <CA+-zrRLWnPe8T9WjWcER7NZSuh5nJVmG4jEqRcvTnqjY4LsbjA@mail.gmail.com>
References: <CA+-zrRLWnPe8T9WjWcER7NZSuh5nJVmG4jEqRcvTnqjY4LsbjA@mail.gmail.com>
From: Zameer Manji <zmanji@apache.org>
Date: Wed, 21 Sep 2016 10:07:12 -0700
Message-ID: <CAM+cpfdjOuxzVJWbF8BqLzngfBXaRQ3A-cpza-G2SKLWNVUZrQ@mail.gmail.com>
Subject: Re: Marathon API and support for pods
To: user@mesos.apache.org
Content-Type: multipart/alternative; boundary=001a1145a966c11fe6053d07942e
archived-at: Wed, 21 Sep 2016 17:07:38 -0000

--001a1145a966c11fe6053d07942e
Content-Type: text/plain; charset=UTF-8

Hey,

Have you considered sending this to your framework's mailing list? As a
Mesos user, I don't think framework specific documents like this need to be
shared with the entire community.


On Wed, Sep 21, 2016 at 2:59 AM, James DeFelice <james.defelice@gmail.com>
wrote:

> Hi folks,
>
> First of all the Marathon team would like to thank those who provided
> feedback on the v3 API proposal (linked below) that was circulated last
> month. Developing a new API for Marathon is a big undertaking and getting
> your feedback early in the process has been helpful.
>
> "A vision for pods in Marathon
> [https://docs.google.com/document/d/1uPH58NWN_
> OuynptsqTOq8v5qlkivq2mUb2M9J5jZTMU/edit#heading=h.sqydeepp9s4m]
>
> We've done some additional discovery over the several weeks and have made
> some changes to our API roadmap. It takes time to get an API right and the
> decisions we make now will have lasting impact for months/years to come;
> let's ensure that we spend enough time now thinking through the long-term
> implications of particular API design choices. We'd also like to facilitate
> a deeper discussion with the community about what problems v3 should solve
> before committing to API decisions. The current plan is to resume work on
> the v3 API later this fall. Stay tuned for additional announcements
> regarding v3 API proposals.
>
> Furthermore, the v3 API is about more than just pods. We, the team and
> community at large, should ensure that a new API is conceptually consistent
> across API types and satisfies not only our short-term goals, but is
> forward-compatible with our long term roadmap.
>
> That said, we have customer demand for pods now! In order to deliver pods
> functionality without committing to a v3 API the team has decided to
> introduce pods via a new /v2/pods API endpoint. What does this mean for v2
> API users?
>
> First, if your organization doesn't have an interest in pods then nothing
> forces you to change. Additional support for pods in the Marathon v2 API
> should not cause breakage for existing v2 API users.
>
> Second, by integrating with the existing v2 API and backend we'll be
> minimizing overall architectural changes. Needless to say there will be
> changes to backend components that had been previously optimized for single
> tasks vs. task groups. But the overall architecture of the system will not
> change. This is important in order to preserve the performance,
> scalability, and stability gains that Marathon has recently made.
>
> In addition, introducing pods in v2 allows the Marathon team to gather
> early feedback from the community and our customers about how the API does
> and does not meet their needs. This is very valuable input that will help
> to shape the future v3 API.
>
> Below is a link to a proposal for pods in the Marathon v2 API. This
> initial implementation for pods support should be viewed as an MVP that
> will be enhanced in coming releases. Your feedback is most welcome and
> strongly encouraged. Please comment directly in the document with any
> questions or concerns.
>
> "Marathon: Pods in v2"
> [https://docs.google.com/document/d/1Zno6QK2yGF4koB8BYT88EtB2-
> T7t3aAYRQ27pUD76gw/edit#heading=h.ywxj299mstr7]
>
> Many thanks,
>
> the Marathon team.
>

--001a1145a966c11fe6053d07942e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hey,<div><br></div><div>Have you considered sending this t=
o your framework&#39;s mailing list? As a Mesos user, I don&#39;t think fra=
mework specific documents like this need to be shared with the entire commu=
nity.</div><div><br></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Wed, Sep 21, 2016 at 2:59 AM, James DeFelice <span dir=
=3D"ltr">&lt;<a href=3D"mailto:james.defelice@gmail.com" target=3D"_blank">=
james.defelice@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">Hi folks,<br><br>First of all the Marathon team woul=
d like to thank those who provided feedback on the v3 API proposal (linked =
below) that was circulated last month. Developing a new API for Marathon is=
 a big undertaking and getting your feedback early in the process has been =
helpful.<br><br>&quot;A vision for pods in Marathon<div>[<a href=3D"https:/=
/docs.google.com/document/d/1uPH58NWN_OuynptsqTOq8v5qlkivq2mUb2M9J5jZTMU/ed=
it#heading=3Dh.sqydeepp9s4m" target=3D"_blank">https://docs.google.com/<wbr=
>document/d/1uPH58NWN_<wbr>OuynptsqTOq8v5qlkivq2mUb2M9J5j<wbr>ZTMU/edit#hea=
ding=3Dh.<wbr>sqydeepp9s4m</a>]<br><br>We&#39;ve done some additional disco=
very over the several weeks and have made some changes to our API roadmap. =
It takes time to get an API right and the decisions we make now will have l=
asting impact for months/years to come; let&#39;s ensure that we spend enou=
gh time now thinking through the long-term implications of particular API d=
esign choices. We&#39;d also like to facilitate a deeper discussion with th=
e community about what problems v3 should solve before committing to API de=
cisions. The current plan is to resume work on the v3 API later this fall. =
Stay tuned for additional announcements regarding v3 API proposals.<br><br>=
Furthermore, the v3 API is about more than just pods. We, the team and comm=
unity at large, should ensure that a new API is conceptually consistent acr=
oss API types and satisfies not only our short-term goals, but is forward-c=
ompatible with our long term roadmap.<br><br>That said, we have customer de=
mand for pods now! In order to deliver pods functionality without committin=
g to a v3 API the team has decided to introduce pods via a new /v2/pods API=
 endpoint. What does this mean for v2 API users?<br><br>First, if your orga=
nization doesn&#39;t have an interest in pods then nothing forces you to ch=
ange. Additional support for pods in the Marathon v2 API should not cause b=
reakage for existing v2 API users.<br><br>Second, by integrating with the e=
xisting v2 API and backend we&#39;ll be minimizing overall architectural ch=
anges. Needless to say there will be changes to backend components that had=
 been previously optimized for single tasks vs. task groups. But the overal=
l architecture of the system will not change. This is important in order to=
 preserve the performance, scalability, and stability gains that Marathon h=
as recently made.<br><br>In addition, introducing pods in v2 allows the Mar=
athon team to gather early feedback from the community and our customers ab=
out how the API does and does not meet their needs. This is very valuable i=
nput that will help to shape the future v3 API.<br><br>Below is a link to a=
 proposal for pods in the Marathon v2 API. This initial implementation for =
pods support should be viewed as an MVP that will be enhanced in coming rel=
eases. Your feedback is most welcome and strongly encouraged. Please commen=
t directly in the document with any questions or concerns.<br><br>&quot;Mar=
athon: Pods in v2&quot;<br>[<a href=3D"https://docs.google.com/document/d/1=
Zno6QK2yGF4koB8BYT88EtB2-T7t3aAYRQ27pUD76gw/edit#heading=3Dh.ywxj299mstr7" =
target=3D"_blank">https://docs.google.com/<wbr>document/d/<wbr>1Zno6QK2yGF4=
koB8BYT88EtB2-<wbr>T7t3aAYRQ27pUD76gw/edit#<wbr>heading=3Dh.ywxj299mstr7</a=
>]<br><br>Many thanks,<br><br>the Marathon team.
</div></div>
</blockquote></div><br></div>

--001a1145a966c11fe6053d07942e--