+1, good info - wrong forum. On Wed, Sep 21, 2016 at 11:07 AM, Zameer Manji <[email protected]> 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 <[email protected]> > 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. >> > >
