mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilbert Song" <>
Subject Re: Review Request 39331: Support docker local store pull image simultaneously
Date Tue, 17 Nov 2015 17:43:33 GMT

This is an automatically generated e-mail. To reply, visit:

(Updated Nov. 17, 2015, 9:43 a.m.)

Review request for mesos, Anand Mazumdar, Jie Yu, Jojy Varghese, and Timothy Chen.

Bugs: MESOS-3736

Repository: mesos


Support docker local store pull image simultaneously

Diffs (updated)

  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 edfbb6fe932173dcbb15133e0eb685d86dd09c00



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.


Gilbert Song

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message