+1, good info - wrong forum.

On Wed, Sep 21, 2016 at 11:07 AM, Zameer Manji <zma...@apache.org> wrote:

> 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.defel...@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_OuynptsqTOq8v5
>> qlkivq2mUb2M9J5jZTMU/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/1Zno6QK2yGF4koB8BYT88EtB
>> 2-T7t3aAYRQ27pUD76gw/edit#heading=h.ywxj299mstr7]
>> Many thanks,
>> the Marathon team.

Reply via email to