> On Sept. 10, 2015, 3: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". > > Timothy Chen wrote: > Dropping this for now as it's going to be addressed later.
That's fine. Mind if I create a ticket to track? Another chance for me to articulate the need for it. - Jiang Yan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/38137/#review98216 ----------------------------------------------------------- On Sept. 22, 2015, 3: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, 3: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 > >
