mesos-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zameer Manji <>
Subject Re: Marathon API and support for pods
Date Wed, 21 Sep 2016 17:07:12 GMT

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

> 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
> [
> 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"
> [
> T7t3aAYRQ27pUD76gw/edit#heading=h.ywxj299mstr7]
> Many thanks,
> the Marathon team.

View raw message