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_ > 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. >
