> On Sept. 10, 2015, 10:04 a.m., Jiang Yan Xu wrote:
> > src/slave/containerizer/provisioners/docker.cpp, lines 104-107
> > <https://reviews.apache.org/r/38137/diff/5/?file=1066157#file1066157line104>
> >
> >     I guess you are modeling this after the `docker pull` syntax here: 
> > `[REGISTRY_HOST[:REGISTRY_PORT]/]NAME[:TAG]`
> >     
> >     I found that some docker help pages have conflicting use of repository 
> > vs. name and we should probably refer to the spec.
> >     
> >     I think the following questions need to be answered:
> >     
> >     1) If we use image name as the indentifier, it defines "what the image 
> > is". The registry specifies "where the image comes from". If an identical 
> > image is hosted on two registries, should they have the same name?
> >     
> >     2) ID. `docker pull` supports @sha256 syntax and `repositories` file 
> > (which our docker metadata file is modeled after) maps repo:tag to an image 
> > ID. Shouldn't the ID be part of the name? If ubuntu:latest changes when use 
> > releases come out, I don't think repo:tag uniquely identifies the image.
> 
> Timothy Chen wrote:
>     I think I'm trying to conform to the docker client experience, which is 
> what users perceive is the standard.
>     Although docker supports sha256 syntax, users still all the time refers 
> to images as [registry_host:port]/repository:tag. When images are conflicting 
> between two registries, the user is usually impliciting defining which one to 
> pick based on the registry source. If user swithces the default registry and 
> we are now not in sync, this is at least identical to what docker client 
> behaves today and users should expect the same. We will provide comments in 
> the user guide.
>     
>     The current docker client simpliy matches the full name like we do in the 
> code here, and caches that tag until a docker pull happens that attempts to 
> get the latest tag.
>     
>     And yes Docker doesn't consistently name things correctly themselves :( 
> I'm going with the Docker registry API naming for now, which is repository 
> instead of name.
> 
> Jiang Yan Xu wrote:
>     I am all for not diverging from the "standard" docker user experience 
> here but I think 
>     1) We have to support specifying image by ID.
>     
>     Docker's tags are imprecise and mutable, as a large organization running 
> production services we have to have the option to be very precise about what 
> to deploy. If users don't want to be precise, they don't have to use it.
>     
>     2) From what I can tell, registry is not persisted in the "repositories" 
> file, so how does Docker engine know the locally cached image with the same 
> repo:tag matches a request for "myregistry/repo:tag" or not?
>     
>     I am actually digging through docker code so feel free to share the link.
> 
> Jiang Yan Xu wrote:
>     I take back my point 2). Registry is **part of** of the "repo".

Dropping this for now as it's going to be addressed later.


- Timothy


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


On Sept. 22, 2015, 10:15 p.m., Timothy Chen wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38137/
> -----------------------------------------------------------
> 
> (Updated Sept. 22, 2015, 10:15 p.m.)
> 
> 
> Review request for mesos, Jie Yu, Jojy Varghese, Till Toenshoff, and Jiang 
> Yan Xu.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Joining all the commits around provisioner and local store into one review so 
> it's easier to review, as patches
> are changing code on top of each other.
> 
> All the commits are going to committed together.
> 
> 
> Diffs
> -----
> 
>   src/Makefile.am e224060 
>   src/slave/containerizer/provisioner/docker/local_puller.hpp PRE-CREATION 
>   src/slave/containerizer/provisioner/docker/local_puller.cpp PRE-CREATION 
>   src/slave/containerizer/provisioner/docker/message.hpp PRE-CREATION 
>   src/slave/containerizer/provisioner/docker/message.proto PRE-CREATION 
>   src/slave/containerizer/provisioner/docker/metadata_manager.hpp 
> PRE-CREATION 
>   src/slave/containerizer/provisioner/docker/metadata_manager.cpp 
> PRE-CREATION 
>   src/slave/containerizer/provisioner/docker/paths.hpp PRE-CREATION 
>   src/slave/containerizer/provisioner/docker/paths.cpp PRE-CREATION 
>   src/slave/containerizer/provisioner/docker/puller.hpp PRE-CREATION 
>   src/slave/containerizer/provisioner/docker/puller.cpp PRE-CREATION 
>   src/slave/containerizer/provisioner/docker/store.hpp PRE-CREATION 
>   src/slave/containerizer/provisioner/docker/store.cpp PRE-CREATION 
>   src/slave/containerizer/provisioner/store.cpp 35d1199 
>   src/slave/flags.hpp e31a418 
>   src/slave/flags.cpp add4196 
>   src/tests/containerizer/provisioner_docker_tests.cpp 1b0c304 
> 
> Diff: https://reviews.apache.org/r/38137/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Timothy Chen
> 
>

Reply via email to