Conversation
Signed-off-by: Victor Vieux <[email protected]>
|
ping @abronan @aluzzardi |
|
what about |
|
or someway to reuse that flag, unless you really think we need another which i guess we kinda do because having two equals is kinda weird in the case of |
|
@jfrazelle Agreed I like the |
|
|
|
@jfrazelle sorry I misread what you wrote |
|
@jfrazelle yes we could use |
|
+1 for Also a big +1 for doing this on the daemon; Docker Compose can probably benefit from that as well |
|
The thing is, I'm not super confident about using |
Looks like I'm making a fool of myself here; I was misreading your intent, and got confused in the discussion; we already have filtering on label; this is for displaying. /me grabs the hat of eternal shame (still have it lying around somewhere) 😊 |
|
@icecrime @tiborvass @jfrazelle Any update on this ? I still believe |
|
I'm having a hard time following the indent of this issue. I'm guessing you don't want it to filter, rather you JUST want a new column for ALL containers. And that new column shows each container's value for the label "foo". And if it has no label then its blank. Is that correct? |
|
@duglin Yes it's correct. Besides this, we are discussing whether we should use @vieux with a fresher mind after reading the PR again, I think we should use a new flag anyway. The notion of displaying a new column must not be entangled with the filtering of containers output. And using the |
|
@vieux how do you guarantee that a user-defined label isn't going to conflict with a swarm defined label? Or that a user doesn't change the value on you? It feels a bit like there needs to be either a) clear rules for how docker defined extensions (labels) are defined vs user-defined ones to avoid conflicts, or b) a docker/swarm managed set of extension properties that users can't touch. |
Aren't namespaces meant for that? i.e. |
|
yes. I was just looking at the example he provided in the first comment ("storage") and didn't realize it was a short-hand for something like com.docker.swarm.storage. Should make for one heck of a column title :-) |
|
@duglin this is more of a swarm design problem than docker, but we could also refuse to schedule containers if they already have a |
|
needs a rebase |
|
Compose would benefit from this as well. If certain labels could be exposed through the list containers API call, it would remove the need to inspect every container that was returned to get the labels. |
|
Closing in favor of #12931 |
I didn't write the documentation yet, because I'd like to know what you think beforehand.
I'd like to add a
--labeltodocker psso if you doyou get
Everything could be done client side, but I decided to go through the daemon, so, it the future the daemon could add mandatory labels to display. (key
Displayin the JSON)If this PR gets merged, we are going to use this feature in Swarm to add a mandatory label
node, sodocker pswill output: