Pinging Jie and MPark... On Thu, Sep 24, 2015 at 4:14 PM, Vaibhav Khanduja <[email protected] > wrote:
> Adam > > Thanks for your reply. > > I was wondering if you could share more details on the implementation of > this falling into docker volumes? I see the code under checkPointResource > is creating a volume path under sandbox. Do these checkpointed resource > finally get added to Docker:ContainerInfo? If yes, can you point me to that > location. > > Thanks > > On Fri, Sep 11, 2015 at 10:35 PM, Adam Bordelon <[email protected]> > wrote: > > > Vaibhav, > > > > The CheckpointResourcesMessage is sent from the master to the slave > > whenever there is a change in dynamic reservations, or if a persistent > > volume is newly created/destroyed. Each slave must checkpoint (persist to > > disk) enough metadata about its reservations/volumes in case the slave > > process fails over, and the slave has to report its existing > > reservations/volumes to a new master. If this information was not > > persisted, then Mesos might forget about reservations/volumes, and they > > could not be respected/released. Jie and MPark can elaborate. > > > > Note that we are not (yet) checkpointing in-memory task/container state. > > That's a future feature for Dr. Kapil. > > > > On Wed, Sep 2, 2015 at 12:23 PM, Khanduja, Vaibhav < > > [email protected] > > > wrote: > > > > > @ > > > > > > I apologies for flooding mail boxes but was wondering if I could get > more > > > info on “CheckPoint Resource”. I see slave code and find following > code: > > > > > > " > > > > > > void Slave::checkpointResources(const vector<Resource>& > > > _checkpointedResources) > > > > > > " > > > Does CheckPoint resource mean the state of the resource can be > > > preserved/CheckPointed? I got reached to this code while understanding > > > persistent volume implementation in 0.24. > > > > > > Thanks > > > > > >
