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 Proposal: Add label support to update command #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 Proposal: Add label support to update command #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.