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

Container displays label from another container #8545

Closed
aviratna opened this issue May 7, 2019 · 5 comments · Fixed by #8558
Closed

Container displays label from another container #8545

aviratna opened this issue May 7, 2019 · 5 comments · Fixed by #8558
Assignees

Comments

@aviratna
Copy link

aviratna commented May 7, 2019

Background
We are using docker label for various use cases like chargeback, load balancer etc. We came across below issue with docker label.

Issue: If we create a container with docker label and use same docker image to create another container, new container will get created with same docker label though we did not provide the docker label for new container.

vSphere and vCenter Server version
vSphere 6.5

VIC version
VIC 1.5 (probably all versions in the past too)

##### Steps to reproduce

  1. Create a container with docker label
    e.g. docker run --label xyz :
  2. Check for docker label
    docker inspect <container id 1>
  3. Create another container using same docker image. do not pass label parameter
    docker run :
  4. Check the docker label
    docker inspect <container id 2>
  5. New docker container also shows the same docker label from previous container created using same docker image though we did not provided the docker label in docker run.

##### Actual behavior
Container copies the label from another container which are created using same docker image.

##### Expected behavior
Container should only show docker label which are part of docker image or docker label provided during docker run command. Container should not copy label from another container.

Docker Image is immutable, it should not get updated with docker label provided during docker run.

##### Observation
We tried the docker inspect on docker image. Labels got updated for that docker image which were provided during docker run command.

@malikkal

@wjun
Copy link
Contributor

wjun commented May 9, 2019

@aviratna I cannot reproduce the issue in VIC 1.5.2, and I think there is no change related to label between VIC 1.5.0 and VIC 1.5.2. You may double check here.

@aviratna
Copy link
Author

@wjun we verified this issue on VIC 1.5.2, we are able to reproduce it.

Below are steps and our observation:

  1. Create a 1st container from docker image and pass --label parameter.
  2. docker inspect container id shows the label which is expected.
  3. Same label gets updated for docker image as well. you can verify it by doing "docker inspect image."
  4. docker inspect image should not show labels which were attached to container.
  5. When we try creating 2nd container from same docker image without --label parameter, labels gets attached from docker image. This container should get create without any docker label.

We can not use different docker labels for different containers created from same docker image because of this issue.

Docker Image Inspect: Labels updated for docker image which were passed as parameter during container creation.

image

Please let us know if any logs or any additional details are required.

@malikkal

@wjun
Copy link
Contributor

wjun commented May 17, 2019

These are the steps I use when trying to reproduce by creating two containers from the same image and one with label another one without. it works as expected:
551 docker -H 10.192.200.165:2376 --tls --tlscacert=certs/ca.pem --tlscert=certs/client-crt.pem --tlskey=certs/client-key.pem run -id --label pen: busybox
552 docker -H 10.192.200.165:2376 --tls --tlscacert=certs/ca.pem --tlscert=certs/client-crt.pem --tlskey=certs/client-key.pem ps
553 docker -H 10.192.200.165:2376 --tls --tlscacert=certs/ca.pem --tlscert=certs/client-crt.pem --tlskey=certs/client-key.pem inspect flamboyant_bell
554 docker -H 10.192.200.165:2376 --tls --tlscacert=certs/ca.pem --tlscert=certs/client-crt.pem --tlskey=certs/client-key.pem run -id busybox
555 docker -H 10.192.200.165:2376 --tls --tlscacert=certs/ca.pem --tlscert=certs/client-crt.pem --tlskey=certs/client-key.pem ps
556 docker -H 10.192.200.165:2376 --tls --tlscacert=certs/ca.pem --tlscert=certs/client-crt.pem --tlskey=certs/client-key.pem inspect modest_carson

Please paste the docker commands you use here and see if we can reproduce. Or you can try the above commands in your local environment.

@aviratna
Copy link
Author

aviratna commented May 28, 2019

@wjun Hi, I did some test on docker label to reproduce it.

  1. Issue is reproducible on docker image which already has some label
  2. Issue is not reproducible if docker image has no label or null

E.g
Docker Image without Label: golang:1.10
Docker Image with label: nginx:1.13.5-alpine or rhel:7.4-152

Step:

  1. When you create a container from docker image which already some labels and
    docker run --label="service_name=web1" nginx:1.13.5-alpine
  2. Container will get created, if you do docker inspect . You can see image label as well custom label pass during container creation
  3. Docker image inspect nginx:1.13.5-alpine shows the previous labels as well as label parameter provided during container creation. Docker Image should not get updated with container label.
  4. When we try to provision another container from same docker image without any custom label parameter, newly provisioned container also gets attached with labels from previous container.

Docker Image inspect:

image

Please let us know if any logs or additional details are required.

One more observation: If we restart the VCH endpoint, issue will be fixed. Custom Docker label will be deleted from docker image and container which was created without docker label parameter.
Issue is reproducible again if we follow the above mentioned steps.

Not sure if its related to VCH cache.

@malikkal

@wjun wjun self-assigned this May 29, 2019
@wjun
Copy link
Contributor

wjun commented May 29, 2019

@aviratna Thanks for the information, and now I understand when the issue happens. The PR above should able to fix this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants