Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use user provided image name to launch container #4926

Merged
merged 1 commit into from
Nov 30, 2018
Merged

Conversation

notnoop
Copy link
Contributor

@notnoop notnoop commented Nov 27, 2018

This allows the container to be tagged with a user friendly image name
(e.g. redis:3.2) rather than the image ID (e.g.
sha256:87856cc39862cec77541d68382e4867d7ccb29a85a17221446c857ddaebca916).

Useful for human debugging, as well as some debugging and image scanning
tools.

This risks two bad side-effects

  1. Discrepancy in image resolution between docker and Nomad's image
    loader.

    • I checked the image creation paths in Nomad, and noticed that we
      either pulled the image or inspect the image with the user provided
      name.
  2. A race in image tagging where the tag is modified between image
    loading and container creation.

    • I, personally, don't think this case is cause for concern, as it is
      analogous to the task running a bit later. As long as the image is
      still present, creating the container should be good.

Closes #2624

This allows the container to be tagged with a user friendly image name
(e.g. `redis:3.2`) rather than the image ID (e.g.
`sha256:87856cc39862cec77541d68382e4867d7ccb29a85a17221446c857ddaebca916`).

Useful for human debugging, as well as some debugging and image scanning
tools.

This risks two bad changes:
1. Discrepancy in image resolution between docker and Nomad's image
loader.
  * I checked the image creation paths in Nomad, and noticed that we
either pulled the image or inspect the image with the user provided
name.

2. A race in image tagging where the tag is modified between image
loading and container creation.
  * I, personally, don't think this case is cause for concern, as it is
analogous to the task running a bit later.  As long as the image is
still present, creating the container should be good.
@nickethier
Copy link
Member

@rcgenova

Copy link
Member

@nickethier nickethier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add an entry to the CHANGELOG please, then LGTM

@notnoop notnoop merged commit ef42413 into master Nov 30, 2018
@notnoop notnoop deleted the f-docker-image-ref branch December 5, 2018 00:50
@github-actions
Copy link

I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants