Hi, We're actively seeking to build a few primitives in Mesos which would allow us to run stateful services (like HDFS) on Mesos (see MESOS-1554 <https://issues.apache.org/jira/browse/MESOS-1554>).
We've been iterating on the design for a while (mainly Mesosphere and Twitter). We've put together an preliminary design doc <https://docs.google.com/document/d/1GwI0gk6oZHL3tJbdZRFstnUftR0C4udRY6a-l9XRhgI/edit?usp=sharing> describing our current idea. We would love to hear your thoughts/suggestions/comments. Feel free to comment on that. In fact, the current design is different from our previous design. In order to give you some context, I am also attaching the OLD design doc <https://docs.google.com/document/d/1wkrRHEfYNv87G9BxZnNPZDggbAqZcZK4pcUra4o0gew/edit?usp=sharing>. The following is the highlights about our reasoning why we change to the new design. - Jie The main reason driving us thinking about an alternative is because we > realized that lazy (dynamic) reservation is not a prerequisite for > persistence. We refer to the existing role based reservation as static > reservation. In fact, persistence implies general reservation (static or > lazy). > > If you agree with the above reasoning, then the reservation id in the old > design doc cannot be re-used for persistence because people might use > static reservation to ensure persistent disk resources are not allocated to > others. That implies that we have to have a separate and independent 'id' > for persistent disk resource. > > Another reason we consider using 'role' based lazy reservation (instead of > framework based) is because Christos commented in the old design doc that > we may want lazy reservation/persistence across frameworks. In my mind, the biggest downside of attaching ids to lazy resources is > that, frameworks don't typically care about the specific id of the reserved > resource (cpu id 1 vs cpu id 2) they just care that they are guaranteed to > get back the given amount of resources. Of course this changes a bit for " > persistent disk" and we aim to solve that with DiskInfo which is explicit. >
