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.

Reply via email to