> On Jan. 28, 2014, 9:16 a.m., Vinod Kone wrote: > > src/launcher/fetcher.cpp, lines 41-49 > > <https://reviews.apache.org/r/16147/diff/8/?file=451132#file451132line41> > > > > could we just do 'xf' and let tar figure out the compression?
This was copied straight from the old launcher, but yes. I had thought gnu tar required the flags but I checked now and it confirmed it doesn't > On Jan. 28, 2014, 9:16 a.m., Vinod Kone wrote: > > src/launcher/fetcher.cpp, line 216 > > <https://reviews.apache.org/r/16147/diff/8/?file=451132#file451132line216> > > > > You can kill "uri.has_executable()". This relies on the optional executable defaulting to false - should we make that explicit in the proto file? > On Jan. 28, 2014, 9:16 a.m., Vinod Kone wrote: > > src/launcher/fetcher.cpp, line 222 > > <https://reviews.apache.org/r/16147/diff/8/?file=451132#file451132line222> > > > > Why the extraction in an else loop? Was this the old behavior? > > mesos.proto doesn't say that it is only extracted if it's executable. The old code was: if (executable) { chmod(); } if (archive) { extract(); } But what does it mean for a file to be both executable and an archive!? If it's executable then I don't believe we want to extract it. Is this not correct? Technically, it could be both, e.g., a self-extracting archive, but we don't want to extract these with tar/unzip. > On Jan. 28, 2014, 9:16 a.m., Vinod Kone wrote: > > src/launcher/fetcher.cpp, line 230 > > <https://reviews.apache.org/r/16147/diff/8/?file=451132#file451132line230> > > > > s/a/an/ ? Not for user because it's consonant sounding. > On Jan. 28, 2014, 9:16 a.m., Vinod Kone wrote: > > src/local/local.cpp, line 153 > > <https://reviews.apache.org/r/16147/diff/8/?file=451136#file451136line153> > > > > s/isolator/containerizer/ ? > > > > Do you know what is this TODO about? No, I don't. [~benh], can you please elaborate? > On Jan. 28, 2014, 9:16 a.m., Vinod Kone wrote: > > src/slave/containerizer/containerizer.hpp, lines 77-78 > > <https://reviews.apache.org/r/16147/diff/8/?file=451139#file451139line77> > > > > Isn't this containerizer interface? > > > > s/enabled/enable/ I meant make it non-static so each containerizer implementation determines the resources. I've reworded the TODO to make this clearer. > On Jan. 28, 2014, 9:16 a.m., Vinod Kone wrote: > > src/slave/containerizer/containerizer.cpp, line 225 > > <https://reviews.apache.org/r/16147/diff/8/?file=451140#file451140line225> > > > > Should there be a check here for user specifying cgroups isolation on > > non-linux boxes? The cgroups isolators are conditionally included in the map so specifying them on a non-linux platform will result in a 'not found' error. I've updated the message to include "unsupported isolators". > On Jan. 28, 2014, 9:16 a.m., Vinod Kone wrote: > > src/slave/containerizer/containerizer.cpp, lines 251-253 > > <https://reviews.apache.org/r/16147/diff/8/?file=451140#file451140line251> > > > > No need for "+"s to concatenate!? adjacent string literals are automatically concatenated. > On Jan. 28, 2014, 9:16 a.m., Vinod Kone wrote: > > src/slave/containerizer/mesos_containerizer.cpp, line 209 > > <https://reviews.apache.org/r/16147/diff/8/?file=451142#file451142line209> > > > > Depending on how you fix the above, this should/could not be a CHECK > > either. Kept this here because recover() should not try to _recover() any executors without pids. > On Jan. 28, 2014, 9:16 a.m., Vinod Kone wrote: > > src/slave/slave.hpp, line 266 > > <https://reviews.apache.org/r/16147/diff/8/?file=451153#file451153line266> > > > > not yours but could you s/recoveR/recover/ I originally had this in and [~bmahler] scolded me for included random fixes ;-) > On Jan. 28, 2014, 9:16 a.m., Vinod Kone wrote: > > src/slave/slave.cpp, lines 2041-2046 > > <https://reviews.apache.org/r/16147/diff/8/?file=451154#file451154line2041> > > > > With my recent change to include the first tasks resources when > > launching an executor do we still need this? Removed and I'll rebase. > On Jan. 28, 2014, 9:16 a.m., Vinod Kone wrote: > > src/slave/slave.cpp, line 2081 > > <https://reviews.apache.org/r/16147/diff/8/?file=451154#file451154line2081> > > > > Wouldn't the containerizer destroy it automatically in this case? No, the current semantics are that a container isn't destroyed until you actually call destroy(). Should this be revised? - Ian ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/16147/#review32969 ----------------------------------------------------------- On Jan. 27, 2014, 3 a.m., Ian Downes wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/16147/ > ----------------------------------------------------------- > > (Updated Jan. 27, 2014, 3 a.m.) > > > Review request for mesos, Benjamin Hindman, Ben Mahler, Chi Zhang, Niklas > Nielsen, samya, and Jason Dusek. > > > Repository: mesos-git > > > Description > ------- > > The proposed Containerizer interface is to replace the existing Isolator. > > One ContainerizerProcess has been written: > MesosContainerizerProcess - implements containerizeration internally using a > Launcher and one or more Isolators (following review) > > The intent is to also support a generic ExternalContainerizerProcess that can > delegate containerizeration by making external calls. Other Containerizers > could interface with specific external containerization techniques such as > Docker or LXC. > > > Diffs > ----- > > include/mesos/mesos.proto 655f86757487ddbe551fdcf53eb793e773ecdd34 > src/Makefile.am cf0c8c66e8dd21c2f5a2da22e5d5adb056353454 > src/common/type_utils.hpp 3b05751a9a27055dd19e4abb79197f53e5554fe1 > src/launcher/fetcher.cpp PRE-CREATION > src/launcher/launcher.hpp 104fe812ddd2b75b14ec0b40d192f58cdba3603a > src/launcher/launcher.cpp d5ab66704429a95eeb8eda5188e33d8e691221af > src/launcher/main.cpp de64609905ee63096c0173fe7e64a1eafea5d6bf > src/local/local.cpp 83a7f913afb1441e9137c7fcec8fd81815714905 > src/slave/cgroups_isolator.hpp e86062e9abaaa263c32c55e9dbfefd700f605886 > src/slave/cgroups_isolator.cpp 80155a3f0cd684a6aad9a37f61c5204d86032735 > src/slave/containerizer/containerizer.hpp PRE-CREATION > src/slave/containerizer/containerizer.cpp PRE-CREATION > src/slave/containerizer/mesos_containerizer.hpp PRE-CREATION > src/slave/containerizer/mesos_containerizer.cpp PRE-CREATION > src/slave/flags.hpp 827b2d0d6dc8fa279f3187a09e5dc6d4799d17cd > src/slave/http.cpp c8357e214d2adf2cd712072f58d07b07badb79dc > src/slave/isolator.hpp 9634535d8c746597b4bb6e278587a1b9ca8f1608 > src/slave/isolator.cpp c9643cf9c5657bc142482a71fb161233bffb3b9f > src/slave/main.cpp e0cae7b205c2599e05c4db990cc9c8e9e3673c37 > src/slave/monitor.hpp 52568ad8ec566f7cf36c249c76d798d44eacb578 > src/slave/monitor.cpp a931c4f35a8793c66ee03de82f0e0a21b92f8ffa > src/slave/paths.hpp b1a56a346ca84e7e71c31386602264c5097ef1cf > src/slave/process_isolator.hpp 4ae093fe65775a2b9bec42071961dd58aa0c3d8b > src/slave/process_isolator.cpp 0bc698f04f7c8eaad166dc9d646e13310129dd01 > src/slave/slave.hpp 38ba7b6d6c35f0668d2f021a1285363cbf4367f4 > src/slave/slave.cpp 8b83dacad802a5434bf76ca075b2b8113ed14a84 > src/slave/state.hpp 78b20ffae1f2f629d851784302648e3bf5349321 > src/slave/state.cpp 93cde0c2efbbe5387448631a02e64b20a3d021c1 > src/slave/status_update_manager.hpp > 06ea4659cdd24cb1b82f389f404566ba14a663fb > src/slave/status_update_manager.cpp > 03f5eafefd6ed748bfd4511d654c23c7b460db66 > > Diff: https://reviews.apache.org/r/16147/diff/ > > > Testing > ------- > > > Thanks, > > Ian Downes > >
