inline
----- Original Message -----
> From: "Jie Yu" <[email protected]>
> To: "mesos" <[email protected]>
> Sent: Friday, February 20, 2015 7:37:30 PM
> Subject: Meeting notes about reservations
>
> Hi,
>
> BenM, BenH, MPark and I had a sync today discussing reservations
> (dynamic+static) in Mesos. It was a very productive meeting and here are
> some notes I took from the meeting. I think all of us are on the same page
> now and are happy with the current design.
>
> - Jie
>
> --------
>
> 1) we still keep the static reservation, but we don't introduce a new
> reservation type for that. If role = R and reservation is none, then it's
> statically reserved (cannot be released by anyone).
>
> 2) /reserve and /unreserve endpoints.
>
> Specify the role, slaveid (or hostname, or both, and we validate),
> resources when reserving resources. It only takes resources from static *
> resources. The operator can reserve both OP and FW reservations.
>
> When hit the reserve endpoint, we use the offered resources and invoke the
> offer rescind mechanism.
>
> Question: should we release dynamic reservations when a framework is
> shutting down? Multiple frameworks might share the same role!
>
> 3) reservation id
>
> We might want to have a reservation id (the id can be the framework id as
> well). The goal is to distinguish who reserved this resources if two
> frameworks are under the same role.
>
> 4) introduce principal for reservation
>
> The idea is that we need to track who reserved a resource so that we can
> decide who can unreserve it. The principal and ACLs can help us setup those
> rules for deciding who can unreserve what.
>
How can we define pre-emption policy?
> 5) protobuf
>
> message Resources {
> ...
> message Reservation {
> optional string principal;
> optional string reservation_id; // introduce it later maybe
> }
> ...
> optional string role [ Default = "*" ];
> optional Reservation reservation;
> }
>
--
Cheers,
Timothy St. Clair
Red Hat Inc.
