> On Nov. 10, 2015, 1:59 p.m., Jojy Varghese wrote: > > src/slave/containerizer/mesos/provisioner/docker/store.cpp, line 136 > > <https://reviews.apache.org/r/39331/diff/5/?file=1120529#file1120529line136> > > > > Wondering if you need to pass "recursive" (true) to mkdir. This flag > > ensures that the the whole path of dierctory is created as needed. If its > > already existing, it wont create one.
If "recursive" is set as false explicitly, for the case to mkdir /abc/ef/ghi it would return an error if we do not have /abc/ef existed. We should want it true to create directory tree. - Gilbert ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/39331/#review105965 ----------------------------------------------------------- On Nov. 11, 2015, 9:49 a.m., Gilbert Song wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/39331/ > ----------------------------------------------------------- > > (Updated Nov. 11, 2015, 9:49 a.m.) > > > Review request for mesos, Anand Mazumdar, Jie Yu, Jojy Varghese, and Timothy > Chen. > > > Bugs: MESOS-3736 > https://issues.apache.org/jira/browse/MESOS-3736 > > > Repository: mesos > > > Description > ------- > > Support docker local store pull image simultaneously > > > Diffs > ----- > > src/slave/containerizer/mesos/provisioner/docker/store.hpp > 95e46b9914c018b3e2472f98a54bc33ff9a46e17 > src/slave/containerizer/mesos/provisioner/docker/store.cpp > 6fdb85b3d55339556b0982598d2e5258f6159466 > src/tests/containerizer/provisioner_docker_tests.cpp > 2efe64f7896beb97f14aa2754569bd8383a67ac7 > > Diff: https://reviews.apache.org/r/39331/diff/ > > > Testing > ------- > > make check (ubuntu14.04 + clang-3.6) > > *This is not ready to be merged. > *Still considering two question: > 1. Handling simultaneous failure. If the first request is called and is > written into the hashmap. All the other requests will be waiting for the > future of the first request. But because its return type is > 'Future<vector<string>>', if its future status is 'FAILED/DISCARDED', the > other requests will be waiting forever. > Solved by logic check: if it is the first call to get() Image_A, promise > associate with metadateManager->get(). If not, check whether that promised > future failed/discarded. If yes, over write to the hashmap. > > 2. The current hashmap uses 'stringify(image::name)' as key, but it may not > be unique because there is chance that layer_ids can be changed. > One solution is to have 'stringify(image)' as key. > > > Thanks, > > Gilbert Song > >
