[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16674800#comment-16674800 ] Zhankun Tang commented on YARN-8927: [~eyang] , Thanks. I see what I'm missing. {code:java} if trust local image (or trust local image in a list) { docker image if exists { docker run } else { helper(); } } else { helper(); } function helper() { ... if (allow) { docker pull docker run } } {code} I thought "docker pull" can only be invoked by YARN-3854. And I thought "docker.trusted.local.images" should only contain real existing images. In the psedu-code, it can also be pulled if not exist. If c-e can also run docker pull as above pseudo-code. That makes sense to me. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > Labels: Docker > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16674740#comment-16674740 ] Eric Yang commented on YARN-8927: - [~tangzhankun] Pseudo code is: {code} if trust local image (or trust local image in a list) { docker image if exists { docker run } else { helper(); } } else { helper(); } function helper() { allow=false; if (image does not container "/" and docker.trusted.registry has "library") { allowed = true; } else { allowed = image in docker.trusted.registry or docker.privileged-containers-registry; } if (allow) { docker pull docker run } } {code} When local image is disable or not listed, then registry image take precedence. This solves the 78% of majority who trust latest greatest image from remote repositories. If trust local image option is enabled, local image take precedence over remote repositories. There is no state to remember in Java because docker image command retains the memory if the image is available locally. C-e test is simple and fast by comparing config value with docker image command without having to touch remote repository for the checks. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > Labels: Docker > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16674660#comment-16674660 ] Zhankun Tang commented on YARN-8927: [~eyang] , for the splitting configuration by run and pull. That's just a suggestion. I agree that we should think more and establish a good design in point 1 to avoid a revisit. How the idea of the split into pull and run comes up might be helpful for your reference. When I think how "YARN-3854" would decide what repo it can pull from and run. Something is unclear for the local image settings "docker.trusted.local.image". *Now I seem to prefer the "docker.trusted.local.image" is a white-list.* Consider below scenario with boolean flag: {code:java} "docker.trusted.local.image" = false "docker.trusted.registries" = "cmp1, library" {code} When a user request "cmp1/img1" or "centos:latest", YARN-3854 may download it first if no local image because we trust "cmp1" and Docker hub. And then when c-e wants to run the container, it should first check if this "cmp1/img1" is really local. If it is local before the YARN-3854, deny it because "docker.trusted.local.image" is false. Else, allow it to run based on privilege/mount white-list check result. This seems to require YARN to maintains a list of local images in advance in java layer because c-e is not long-running. Although passing the list to c-e and let c-e do the check is possible, this seems unsmooth or complex. And we need to handle NM restart and load back the original local images names. So it seems the "_docker.trusted.local.image_" should be a white-list to avoid above complexity. And the name can be like: {code:java} "docker.trusted.local.images" = "cmp1/img1,centos" "docker.trusted.registries" = "cmp1,library" {code} But the above configuration still seems not that straightforward to me. So the below configurations comes up in my mind: {code:java} "docker.pull.trusted.registries" = "cmp1,library" "docker.run.trusted.registries" = "cmp1,library" {code} Please correct me if I missed something important. I've no strong opinion on either configuration. Any thoughts? [~eyang] , [~ebadger] > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > Labels: Docker > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16674622#comment-16674622 ] Zhankun Tang commented on YARN-8927: [~eyang] , sorry for the improper statement of the "The problem .." in point 1. Yeah. we could add a check function like your pseudo-code to allow top-level image. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > Labels: Docker > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1667#comment-1667 ] Eric Yang commented on YARN-8927: - {quote}But for point 1, "docker.trusted.registries" will be all about non-local repo. The problem is that doesn't implement how to configure the trust of top-level images like "centos[:tag]". Let's say, configured "library" keyword, top-level pattern image name is trusted.{quote} In pseudo code, can we write: {code} if (image does not container "/" and docker.trusted.registry has "library") { allowed = true; } else { check image repository in docker.trusted.registry; } {code} We should never split the configuration by pull and run. They are executed in the same flow, making distinction between them can prevent program from working and confuse system admin. {quote}For point 2, if we have a "docker.privileged.registries", does it mean the existing "docker.privileged-containers.enabled" will be useless? And for the mount stuff, how will we handle the relationship with existing "docker.allowed.ro-mounts" and "docker.allowed.rw-mounts"? Also deprecated them?{quote} Sorry, it is a typo. I meant to say docker.privileged-containers.registries. I am trying to allow implementation to happen in the order of 1, 2 and 3 without having to revisit logic for 1, when 2 is implementing. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > Labels: Docker > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16674357#comment-16674357 ] Zhankun Tang commented on YARN-8927: [~eyang], Thanks for the explanation. To make us in the same context. I list my understanding and questions as below. Please correct me if anything wrong. First of all, I understand the above configurations are effective for both "docker pull" and "docker run". YARN-3854's request of "docker pull" to container-executor will be denied by if not fit in white-list. The request of a running container will be denied by c-e if not fit in white-list. For point 1, "_docker.trusted.registries_" will be all about non-local repo. The current logic underneath "docker.trusted.registries" already support private trusted registries and docker hub. But it doesn't implement how to configure the trust of top-level images like "centos[:tag]". We only need to add a check related to "library" keyword in c-e. Configured "library" keyword, top-level pattern image name is trusted. It can be pulled. But when run, the local image check will be done based on "_docker.trusted.local.image_". Right? If so, I feel this configuration is only useful for pull ? Maybe the name is not proper? For point 2, if we have a "_docker.privileged.registries_", does it mean "_docker.privileged-containers.enabled_" will be useless? And for the mount stuff, how will we handle the relationship with existing "docker.allowed.ro-mounts" and "docker.allowed.rw-mounts"? Also deprecated them? > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > Labels: Docker > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16674136#comment-16674136 ] Eric Yang commented on YARN-8927: - [~tangzhankun] Kind of, and we add more fine grained controls. The summarized guideline are: # docker.trusted.registries that can trust images on dockerhub as well as private trusted registries. If "library" keyword is used, top level images are trusted. # docker.privileged.registries that can run trusted images as privileged user. If "library" keyword is used, top level images can run with privileged. # docker.trusted.local.image[s] and docker.privileged.local.image[s] are either Boolean flag to trust all local images or work as a list that white list certain local images. (To be discussed in YARN-8955). > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > Labels: Docker > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16673971#comment-16673971 ] Zhankun Tang commented on YARN-8927: [~eyang], sorry for the late reply. Indeed, agree that for the privileged container, we should have more fine-grained control in case malicious image from the public. But I'm not very clear of what the configuration will be like in the end. Are we going to split the "docker.trusted.registries" into several configurations? > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > Labels: Docker > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16667676#comment-16667676 ] Eric Yang commented on YARN-8927: - [~ebadger] Thanks, YARN-8955 is opened for the third issue. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16667627#comment-16667627 ] Eric Badger commented on YARN-8927: --- [~eyang], that sounds good to me. Good idea to open up separate JIRAs so that we don't conflate issues. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16667455#comment-16667455 ] Eric Yang commented on YARN-8927: - {quote}Basically, the mode I'm talking about is allowing users to run privileged containers, but preventing the users from hitting a docker registry. If the library keyword is used, then the user can either specify a local image that exists, or an image in a default registry that exists in the library repository. That's what I'm not comfortable with. I want sysadmins to be able to define that only certain local images can be run as privileged.{quote} There are 3 related issues to what we are discuss here. # The trust of top level public image. (this JIRA) # Privileged container using privileged registry. (YARN-8376) # Trust and privileged local image. (need a new JIRA) It may be best to open a new JIRA to discuss how local image should be trusted and enable privileged container. There are depths in each of the items that need to be designed separately. I am becoming less favoring to use library keyword to combine 1 and 3 together. This JIRA should focus on the original user experience problem of public image. [~ebadger] [~tangzhankun] Do you agree that this is the way forward? > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16667381#comment-16667381 ] Eric Badger commented on YARN-8927: --- Given the risk that's involved with privileged containers, I think it's prudent to be more careful with what images are allowed to be run as privileged. Of course, this is why we have {{docker.trusted.registries}} in the first place. So I'm thinking from the perspective of the sysadmin that wants to have very fine-grained control over exactly what can be run as privileged. There is inherent risk in allowing privileged containers from a docker registry that is not owned by the sysadmin. If that registry is compromised or bad images are pushed, etc. then the cluster could be running malicious images as privileged containers. If the sysadmin can force that the only images that can be run as privileged are local images, then they have control over exactly what images can be run, since they would be the one that puts the local images on the node (could be pulled from a registry, built locally, loaded from a tarball, etc). Basically, the mode I'm talking about is allowing users to run privileged containers, but preventing the users from hitting a docker registry. If the {{library}} keyword is used, then the user can either specify a local image that exists, _or_ an image in a default registry that exists in the {{library}} repository. That's what I'm not comfortable with. I want sysadmins to be able to define that _only_ certain local images can be run as privileged. The way I'd love to do this would be by removing all default registries in Docker itself, but the Docker people seem to be pretty hostile to trying to get rid of default registries or anything related to that (https://github.com/moby/moby/issues/11815). > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1460#comment-1460 ] Eric Yang commented on YARN-8927: - [~tangzhankun] Sorry for the confusion. The "docker run" pull strategy is still being discussed in https://github.com/moby/moby/issues/13331 and https://github.com/moby/moby/issues/34394 . My statement would be inaccurate for "docker run" out side of YARN. Docker run without explicit pull will not update the image to latest. In YARN, there is on going effort to move docker pull into localization phase. If YARN-3854 is done, then it might have pull once and update to latest side effect. The checking logic can be done in localization phase after YARN-3854. I am concerned that YARN's separate effort might be a snow flake effect, if Docker decided to bring 13331 to closure. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1323#comment-1323 ] Zhankun Tang commented on YARN-8927: {quote}There are two docker pull strategy, pull every time vs pull once and update latest. If latest image hash code has changed on docker hub, then it can affect local image to become the latest on docker hub. {quote} [~eyang] , Oh. I don't know this hash code matters. In my understanding, Docker will only pull it if not exist in local. Where can I check this info? And to the YARN image pull policy, I want to first get our consensus on if this "docker.trusted.registries" handle both run and pull? I thought if it doesn't allow, we cannot pull from a repo either. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1118#comment-1118 ] Eric Yang commented on YARN-8927: - [~tangzhankun] There are two docker pull strategy, pull every time vs pull once and update latest. If latest image hash code has changed on docker hub, then it can affect local image to become the latest on docker hub. If I understand [~ebadger] correctly, he would like to change this behavior that it will use the local image and never get the latest from docker hub.until admin explicitly push out image to the nodes. This provides better control of images from system admin's perspective. This means node manager does a docker image list check for the image before launching "docker run" command to determine if there is a local image available. Base on the new behavior of "library" config, node manager will decide to continue or to stop container launch process. This is an arc outside of original design of docker and require more engineering effort and introducing some delays to container localization and launch. I understand the use case, but I am more in favor of setting up the trusted docker repository to track image evolution instead of implementing the arc to prevent implementing snowflakes. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16665934#comment-16665934 ] Zhankun Tang commented on YARN-8927: [~ebadger] , Thanks for the explanation. {quote}One minor detail that we don't agree on is whether we should precheck if image exist locally to prevent docker pull of image to give local image precedence over public image on Docker hub. {quote} If I remember correctly, Docker won't pull image if there's a local one. It only tries to pull if there's NO local image found with required name. So YARN does a precheck here won't give precedence to local because local image already has it. For the docker pull behavior, it may have an explicit control option "--pull" on whether "docker run" will pull if local image not exists. [https://github.com/moby/moby/issues/34394] But whether control pull operation is probably not related to this JIRA. And we have YARN-3854 to do the pull operation for us. But YARN-3854 still will depend on "what are the trusted repositories?". I think the key difference here between us is whether we should provide a switch to exclude trust from "library"'s original meaning in Docker behavior. right? To make sure we're in the same context, I guess what you prefer is to let "library" allow local image and Docker hub but define a switch which can forbid the default Docker hub pull behavior when it found no local image? :) > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16665360#comment-16665360 ] Eric Yang commented on YARN-8927: - [~tangzhankun] [~ebadger] I agreed on using "library" keyword to allow both local and Docker hub is clean and simple. It will satisfy 78% of users. One minor detail that we don't agree on is whether we should precheck if image exist locally to prevent docker pull of image to give local image precedence over public image on Docker hub. In more extreme case, don't ever use Docker hub image, if local image is already available. The best way to solve the minor detail is to have another switch explicitly trust local image. If this option is off, public image will get pulled from docker hub. This gives the most fresh latest image from docker hub. When this option is on, local image take precedence to be used and never get overwritten. This seems like the best way to solve ambiguity. I am in favor of the 78% "library" keyword option because without deploying trusted registry, there is a lot to gamble on local image consistency. There is probably company out there that have developed mechanism to push local images without using a repository. I can't help to think that trust local image option is a snow flake that will fade away when more intelligence is built into YARN's docker pull strategy. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664670#comment-16664670 ] Zhankun Tang commented on YARN-8927: [~eyang] , Sorry for the misleading. I mean we do check with "library" prefix but not using this "library/centos:latest" to replace user's input image name. I agree that we enable local and docker pub repository by default. [~ebadger] Thanks for the detailed discussion here. Really helpful. What YARN does here is adding a white-list for an administrator to allow what "repository/image[:tag] " end user can pull(YARN-3854) or run. To keep the end user's experience of running image without repository name consistent with "Docker", I guess we all agreed that leave "library" in "{{docker.trusted.registries}}" by default to enable local images. Since Docker will try to pull it from docker hub if not in local, should we avoid this pull? I think probably no. The Docker hub could be a trusted repo for YARN. And if not, another problem comes up when only allow real local images: how do we configure Docker hub repo for YARN-3854 to pull images? Use another convention preserved words? So maybe set "library" to "docker.trusted.registries" allowing both local and Docker hub is clean and simple? > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664324#comment-16664324 ] Eric Badger commented on YARN-8927: --- [~eyang], I see your concern now. However, that would still be a problem (albeit to a smaller extent) with using {{library}}. Admins that want to trust local images don't necessarily want to trust the {{library}} repo on dockerhub. Outside of removing all default registries, is there a way to allow trusted local images? We would basically need to make sure that {{docker run}} only ran on local images (which I don't believe is possible) and have a separate pull phase before running. Otherwise, if the image doesn't exist locally it will always go out to the default registries to try and pull it. I guess maybe we could do a check on the local images when we see that there is an image that wants to be run, needs to be trusted, has no registry prepended to the name, and {{docker.trusted.registries}} contains {{library}}. Then we would only run the container if the image in question was already there. But then you couldn't run an image from a default registry from the {{library}} repo unless you gave its full URI. Maybe that's ok. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664312#comment-16664312 ] Eric Yang commented on YARN-8927: - [~ebadger] I am some what concerned with "local" or "localhost" being the name to toggle local registry. "library" is a reserved word from docker point of view. No third party can publish to library without Docker Inc approval or the image is already resided locally and tagged by someone who has docker rights. Unknown party might be able to create a "local" or "localhost" registry on docker hub to defeat the docker.trusted.registries mechanism, if we didn't choose the keyword carefully. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664108#comment-16664108 ] Eric Badger commented on YARN-8927: --- I think a better name would be {{local}} or {{localhost}}. That way it is very clear that this registry entry is referring to the node where the image is being run > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663984#comment-16663984 ] Eric Yang commented on YARN-8927: - I agree that "library" can be the default word to enable local images and public images to be trusted. [~tangzhankun] thoughts? > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663948#comment-16663948 ] Eric Badger commented on YARN-8927: --- bq. Eric Badger This seems to imply that library keyword will toggle to allow public image and image without a registry name. Locally built images will not have registry name. Should we trust all local images without a registry name? I prefer this idea more than prepending library/* but just want to be sure that by common sense, local images can be trusted without getting into trouble. I'm not sure it has to be one or the other. If you specify just {{library}} in the trusted registries then it would mean that all local images are trusted. If you specify {{library/centos:latest}}, then only the {{centos:latest}} image that is local will be trusted and none of the other local images. The main takeaway I want to have here is that the user should not have to change the name of what they're specifying. If the image on the node is {{centos:latest}} then they should ask for {{centos:latest}}, not {{library/centos:latest}}. And there should be a configuration in {{docker.trusted.registries}} to allow for that image to be trusted, even if it is a local image that has no "registry" > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663945#comment-16663945 ] Eric Yang commented on YARN-8927: - {quote}we implicitly transform user given value "centos" to "library/centos:latest", "centos:6" to "library/centos:6".{quote} [~tangzhankun] The idea is good to improve usability. Can user get confused that they ask for centos, but they get library/centos when they run docker inspect command? {quote}If the image is deemed to not have a registry associated with it (e.g. centos:latest or centos:6), we could then mark it as trusted or not based on whether library is in the trusted registries list.{quote} [~ebadger] This seems to imply that library keyword will toggle to allow public image and image without a registry name. Locally built images will not have registry name. Should we trust all local images without a registry name? I prefer this idea more than prepending library/* but just want to be sure that by common sense, local images can be trusted without getting into trouble. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663905#comment-16663905 ] Eric Badger commented on YARN-8927: --- It would be strongly preferable for the user to not have to specify {{library/}} for a local image. If the image is deemed to not have a registry associated with it (e.g. centos:latest or centos:6), we could then mark it as trusted or not based on whether {{library}} is in the trusted registries list. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663236#comment-16663236 ] Zhankun Tang commented on YARN-8927: [~eyang] , Thanks. That works. Configure like below means we trust the local repository and Docker hub. I'll document this. {code:java} docker.trusted.registries=library{code} One thing I'm thinking is that this "library" knowledge is not aware of to most of the docker user. Do we need to make "library" as a default trusted setting and enable the user to use "centos" and "centos[:tag]" as usual to get a consistent experience? In this case, we implicitly transform user given value "centos" to "library/centos:latest", "centos:6" to "library/centos:6". Thoughts? [~eyang], [~leftnoteasy] > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663000#comment-16663000 ] Eric Yang commented on YARN-8927: - [~tangzhankun] {code} docker.trusted.registries=library {code} In the service json, instead of using centos:latest, use library/centos:latest. They are the same image. "library" is the prefix name that Docker hub gave to public images. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16662052#comment-16662052 ] Zhankun Tang commented on YARN-8927: [~eyang] , I don't quite understand. What "docker.trusted.registries" should be set to enable the trust of top-level image name like "centos" or "centos:latest"? > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16661951#comment-16661951 ] Zhankun Tang commented on YARN-8927: [~leftnoteasy] , Yeah. I've figured out these and refine document and code if needed. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16660904#comment-16660904 ] Wangda Tan commented on YARN-8927: -- [~tangzhankun], thanks for filing the Jira, I encountered the issue before and couldn't figure out why. It gonna be worthful to add a description to the container-executor.cfg about how to use this field. We use it as a self-explaining doc for c-e.cfg. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16660881#comment-16660881 ] Eric Yang commented on YARN-8927: - [~tangzhankun] Sorry, my mistake. It is library/centos:latest instead of libraries/centos:latest. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16660813#comment-16660813 ] Zhankun Tang commented on YARN-8927: [~eyang], Thanks for mentioning this. Is the value "libraries" supported yet? I tried but it seems not work. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-8927) Better handling of "docker.trusted.registries" in container-executor's "trusted_image_check" function
[ https://issues.apache.org/jira/browse/YARN-8927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16659105#comment-16659105 ] Eric Yang commented on YARN-8927: - All top level images can be referenced by libraries/* as well. Top level images like centos can be trusted by using docker.trusted.registries=libraries and update the yarnfile to use libraries/centos:latest instead. > Better handling of "docker.trusted.registries" in container-executor's > "trusted_image_check" function > - > > Key: YARN-8927 > URL: https://issues.apache.org/jira/browse/YARN-8927 > Project: Hadoop YARN > Issue Type: Improvement >Reporter: Zhankun Tang >Assignee: Zhankun Tang >Priority: Major > > There are some missing cases that we need to catch when handling > "docker.trusted.registries". > The container-executor.cfg configuration is as follows: > {code:java} > docker.trusted.registries=tangzhankun,ubuntu,centos{code} > It works if run DistrubutedShell with "tangzhankun/tensorflow" > {code:java} > "yarn ... -shell_env YARN_CONTAINER_RUNTIME_TYPE=docker -shell_env > YARN_CONTAINER_RUNTIME_DOCKER_IMAGE=tangzhankun/tensorflow > {code} > But run a DistrubutedShell job with "centos", "centos[:tagName]", "ubuntu" > and "ubuntu[:tagName]" fails: > The error message is like: > {code:java} > "image: centos is not trusted" > {code} > We need better handling the above cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org