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

Proposal: Update labels #21721

Open
vdemeester opened this Issue Apr 1, 2016 · 19 comments

Comments

Projects
None yet
@vdemeester
Copy link
Member

vdemeester commented Apr 1, 2016

This is a follow-up issue to the closed PR #18958 that was only for containers.

Now that networks, volumes, images and containers all support labels, we should probably rethink the idea (or not) of having a common way to update them, instead of only being able to update containers label and no others.

/cc @icecrime @tiborvass @calavera @dnephin @ehazlett

Pasting @tiborvass comment from #20356 (comment) below.


Before going into technical details, I would like to find a good UX. I could come up with these 3 solutions, none of which I really like, but I prefer the 3rd one among these:

  1. For each new object type (images, networks, volumes), add a new update subcommand to match the docker update that is for containers. Questions: is there anything else we would want to update on images networks and volumes? If so what? If we can't agree on those other things to update, then the problem with this solution is we would add a new subcommand just for labels. Moreover, for historical reasons images is not a subcommand the way network and volume are. So if we were to still go with this solution we should also choose between: 1.a) introduce docker images update subcommand OR 1.b) overload docker update the way we (unfortunately) overload docker inspect and accept: docker update --label foo=bar $imageID.
  2. Overload docker update to non-container objects as well. Problem: how to deal with docker update --memory 2G $networkID ? obviously it should error out not recognizing the memory flag for updating network objects, but we would have the same problem docker machine is having with all the cloud-provider-specific flags and it's not ideal for the help output. Also, if we are overloading docker update for non-container objects, why not docker create and more ? Since this solution is a generalization of 1.b, 1.b also suffers of this problem. Both solutions 1 and 2 would result in accepting #18958.
  3. Introduce docker label command that can act on any object. Problem: we already have docker update that updates the container settings (cgroups only for now) and this would be another toplevel command that would also update container settings, albeit only one setting: the labels. As much as I dislike having two commands do similar things, a counter-argument is to say: labels are special because they are meta. Obviously this would mean, the UX in #18958 would be rejected.

If you can think of another solution that would have none of these UX issues, I would be glad to read about it.

@bboreham

This comment has been minimized.

Copy link
Contributor

bboreham commented Apr 1, 2016

is there anything else we would want to update on [...] networks

Of all the current options to docker network create, --ip-range is the main one that seems amenable to changing after the network is in use. And then it would require that the particular IPAM driver is implemented in such a way that its range can be changed.

--opt, which is a catch-all set of options for the driver, is another possibility. Though one might consider replacing this mechanism with labels.

@duglin

This comment has been minimized.

Copy link
Contributor

duglin commented Apr 1, 2016

I'd prefer a top-level "docker image" command and then we can do:

docker image update ...
docker container update ...
docker volume update ...
...

To me, a label isn't a top-level object so having "docker label ..." feels odd. Its a property of some other object.

#13509

@thaJeztah

This comment has been minimized.

Copy link
Member

thaJeztah commented Apr 1, 2016

@duglin's suggestion would be my preferred solution, but obviously the one with most impact as well

@thaJeztah

This comment has been minimized.

Copy link
Member

thaJeztah commented May 20, 2016

Having mutable container (runtime) labels recently came up in a discussion
on the internal Slack channel. A short summary of that discussion;

It's currently not possible to change labels on a running container. In
addition, containers inherit labels from the image they're run from, and any
label set during "docker run", is appended to that list.

  • containers should have mutable (runtime) labels, i.e. I should be able to set
    a active=true label on a container. n.b. UX for setting/unsetting/updating
    labels was not discussed, but should be consistent for all resources, re
    #20356 (comment)
  • container (runtime) and image labels should be separate properties, and not
    be merged. (note: currently, docker run --label foo=bar merges the label with
    labels that are present in the image - so this should change)
  • to preserve backward-compatibility, we can use both "image" and "container"
    labels when filtering, i.e. --filter foo=bar would use both. (Q: in case of
    conflict, which label takes precedence?). It might be easier to give a
    deprecation warning then fix the filter (implementing --filter image-label=xyz=123). Worst case if someone misses the deprecation warning
    they can add the "image" prefix to their code and it will work again
  • to filter containers on by the labels of their image, we can add a
    --filter image-label=xyz=123 (see previous bullet)

/cc @shykes

@aanm

This comment has been minimized.

Copy link
Contributor

aanm commented Jul 3, 2016

@thaJeztah I also think it would be nice to disable labels from a particular image when starting a container.

@creynders

This comment has been minimized.

Copy link

creynders commented Sep 15, 2016

Mutable container labels would be really handy. I'm using traefik, a reverse proxy, which automatically detects docker containers and reads traefik-namespaced container labels for automatic configuration. Setting a label on a running container would allow on-the-fly rule changes.

@blabno

This comment has been minimized.

Copy link

blabno commented Sep 24, 2016

I'm pooling containers that take long time to start and are used later by other containers as dependencies. It would be awesome to mark container as "used" when it gets linked.
Right now I have to maintain map of all containers and their state externally.

@euank euank referenced this issue Oct 12, 2016

Closed

Allow Tags on Containers #16

0 of 18 tasks complete
@yarmiganosca

This comment has been minimized.

Copy link

yarmiganosca commented Dec 15, 2016

In our deployment pipeline, we do blue-green deploys with containers. We launch N new containers, & wait for them to register with consul as healthy before stopping & removing the old containers. If the new containers register as unhealthy, or don't register at all, before our timeout, we stop & remove the new containers. What we'd like to do in that case is keep one of the failed/unhealthy containers around so we can inspect & troubleshoot--a dead canary, if you will. Automating the cleanup of any such dead canary containers on the next deploy gets a lot easier if we can relabel running containers.

@danbeaulieu

This comment has been minimized.

Copy link

danbeaulieu commented May 5, 2017

Similar use case to other users where we pool containers as warm standbys. Once we activate them we'd like to label them for accounting/monitoring etc systems which are part of systems decoupled from the activation system.

@whytoe

This comment has been minimized.

Copy link

whytoe commented Jul 16, 2017

Docker Cloudstor:Azure plugin uses a unique identifier when creating volumes in Azure

screenshot 2017-07-16 at 11 52 19

and it does not input the actual Volume name as an identifier.

Updating a label to correlate the Docker Volume to the Azure "Container" would be very helpful

@sjeeva

This comment has been minimized.

Copy link
Contributor

sjeeva commented Sep 5, 2017

Is label update for containers supported? I couldn't find any options in docker container update command

@jshnaidman

This comment has been minimized.

Copy link

jshnaidman commented Sep 19, 2017

Without being able to update labels, there's currently no way to update any metadata or description or any fields pertaining to a container. Very inconvenient. Would be very useful to be able to update labels or some other custom field.

@g4gupta

This comment has been minimized.

Copy link

g4gupta commented Jan 13, 2018

whats the status here ... am looking for a way to be able to update labels of my images . I would like to manage my images and metadata to them based on their last usage . As such the contents of the image will not change hence I don't want to build a new image version for it to just add /delete some metedata info pertaining to that image .

@aJetHorn

This comment has been minimized.

Copy link

aJetHorn commented Feb 3, 2018

One use case is extremely time-sensitive hotfixes that are done by using docker exec and docker restart. Let's assume it's too time-consuming to send a change through any CD pipeline or even rebuild the container (I understand that in most cases, especially ones using lightweight images this difference is negligible and this approach is unnecessarily dangerous). Once a hotfix is complete, I will use docker commit to create a new image with the proper -hotfix- tag (, do whatever I need to do git-wise) and then upload it to my registry. At that point, I'm guaranteed that the repo image and the running image are running the same code, yet the tag of the running image can't be updated. Being able to affix a "HOTFIX" label before I am able to re-run the image I've committed from the hotfixed container would be helpful. For the sake of example, assume the container in question isn't run redundantly but is high traffic and can only be restarted during one hour of downtime during the day.

@shadowbq

This comment has been minimized.

Copy link

shadowbq commented Aug 14, 2018

Again.. another usecase. v2tec\watchtower will update docker images based on LABELS. If I can dynamically add/remove the labels I can control the automatic update cycle in the case of an upstream bad commit/failing docker image version.

https://github.com/v2tec/watchtower/#selectively-watching-containers

@sooryamanian91

This comment has been minimized.

Copy link

sooryamanian91 commented Sep 13, 2018

Another use case, when updating the labels for K8S PODS using kubectl, the updated POD label would not reflect in the docker container of the POD.

@G1itcher

This comment has been minimized.

Copy link

G1itcher commented Sep 17, 2018

Seeing how many docker tooling images seem to have gravitated towards using labels to define their interactions (watchtower, traefik, etc), it's becoming increasingly important to allow labels to be changed. For example, I have a server with 44 images on them and am looking to move my reverse proxy over the traefik. I now have to go through each image (luckily I made docker-compose files for most of them) and add the appropriate labels and re-up them. Even assuming they all come back okay, that's a big chunk of work

@shenshouer

This comment has been minimized.

Copy link

shenshouer commented Nov 2, 2018

Any plan for this ?

@lucwillems

This comment has been minimized.

Copy link

lucwillems commented Nov 17, 2018

seems swarm service has this option : --container-label-add --container-label-rm
any reason why we can't do this on a "plain" container

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