> On April 7, 2014, 11:44 p.m., Benjamin Hindman wrote:
> > include/mesos/mesos.proto, line 140
> > <https://reviews.apache.org/r/20080/diff/2/?file=550551#file550551line140>
> >
> >     Eventually this will need lots more documentation, here or someplace 
> > else but here is a good source of truth.
> >     
> >     In the mean time, how about a caveat that not all containerizers 
> > currently implement ContainerInfo so it's possible that you'll launch a 
> > task with a container but it will fail.
> >     
> >     Also, can we give at least some explanation of 'image' and 'options'? 
> > Must 'image' be a URI? Etc.
> 
> Till Toenshoff wrote:
>     'image' and 'options' are not really restricted in their exact scheme or 
> even semantics. I did however add a comment that should help explaining this.
>     Deimos does e.g. use 'image' this way: "docker:///ubuntu" as a scheme for 
> pinning docker use and selecting a registered image.
> 
> Benjamin Hindman wrote:
>     If 'image' and 'options' do not have some well know semantics than it'll 
> end up being a total PITA for end users. For example, if one external 
> containerizer program (e.g., Deimos) decides it wants 'docker:///ubuntu' to 
> describe an image but another external containerizer program wants 
> 'docker-image:ubuntu' then we'll have to some how expose to the user which 
> external containerize program is running so that they can conditionally 
> "configure" their ContainerInfo. Ugh, it sounds likes this was not considered 
> in advance. :(
>     
>     My hunch is that we'll be able to define a generic enough scheme for 
> describing containers using 'image' so we can leave it as is for now. 
> Although, I'm less convinced about 'options' ... how is/does Deimos try and 
> use it now?

It has always been my understanding that image is restricted to being a URI. 
The points Ben raises are exactly right on.

Options can be understood as image settings. Deimos passes these options to 
Docker `run`, so they change how the image is launched; but they aren't 
intended to change Docker's behaviour more broadly than that. Notably, global 
Docker settings -- the Docker host, debugging level, &al -- can not be passed 
this way. In one of our clusters, we have Marathon pass bind mounts in the 
options field (["-v", "/etc/secret/stuff"]) for containers that need access to 
certain special credentials; so the options field is important in practice.


- Jason


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20080/#review39746
-----------------------------------------------------------


On April 11, 2014, 2:57 a.m., Till Toenshoff wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20080/
> -----------------------------------------------------------
> 
> (Updated April 11, 2014, 2:57 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Ian Downes, Niklas Nielsen, and 
> Vinod Kone.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Introduces the ContainerInfo protobuf as part of CommandInfo. 
> Right now, if present, the mesos containerizer fails the task launch to point 
> out that we do not support it on that containerizer.
> 
> This will be needed for the ExternalContainerizer and possibly other 
> containerizers as well.
> 
> 
> Diffs
> -----
> 
>   include/mesos/mesos.proto 37f8a7f 
>   src/slave/containerizer/mesos_containerizer.cpp c819c97 
> 
> Diff: https://reviews.apache.org/r/20080/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Till Toenshoff
> 
>

Reply via email to