Hi Tim, The problem of preemption did come up during the discussion, but the plan is to simply not to preempt anything for the first iteration. A reservation request that the master cannot satisfy will simply be rejected. To free resources, an operator can choose to 1. drain the slave (this is no worse than what we have to do today but no better), 2. perform manual preemption by manually killing tasks.
In future iterations, the main idea (we think) will be to leverage the Maintenance Primitives to notify the slave of the upcoming configuration changes and let the frameworks with tasks running on that slave react accordingly. In short, we definitely want to introduce a way to express a preemption policy. But I believe it will be future work. Thanks, MPark. On 21 February 2015 at 06:18, Tim St Clair <[email protected]> wrote: > 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. >
