{"action":"created","issue":{"url":"https://api.github.com/repos/docker/docker/issues/9882","labels_url":"https://api.github.com/repos/docker/docker/issues/9882/labels{/name}","comments_url":"https://api.github.com/repos/docker/docker/issues/9882/comments","events_url":"https://api.github.com/repos/docker/docker/issues/9882/events","html_url":"https://github.com/docker/docker/pull/9882","id":53295819,"number":9882,"title":"Proposal: One Meta Data to Rule Them All => Labels","user":{"login":"ibuildthecloud","id":1754002,"avatar_url":"https://avatars.githubusercontent.com/u/1754002?v=3","gravatar_id":"","url":"https://api.github.com/users/ibuildthecloud","html_url":"https://github.com/ibuildthecloud","followers_url":"https://api.github.com/users/ibuildthecloud/followers","following_url":"https://api.github.com/users/ibuildthecloud/following{/other_user}","gists_url":"https://api.github.com/users/ibuildthecloud/gists{/gist_id}","starred_url":"https://api.github.com/users/ibuildthecloud/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ibuildthecloud/subscriptions","organizations_url":"https://api.github.com/users/ibuildthecloud/orgs","repos_url":"https://api.github.com/users/ibuildthecloud/repos","events_url":"https://api.github.com/users/ibuildthecloud/events{/privacy}","received_events_url":"https://api.github.com/users/ibuildthecloud/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/docker/docker/labels/%2Fproject%2Fdoc","name":"/project/doc","color":"207de5"},{"url":"https://api.github.com/repos/docker/docker/labels/Proposal","name":"Proposal","color":"009800"},{"url":"https://api.github.com/repos/docker/docker/labels/UX","name":"UX","color":"fbca04"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":23,"created_at":"2015-01-03T06:18:06Z","updated_at":"2015-01-09T19:22:45Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/docker/docker/pulls/9882","html_url":"https://github.com/docker/docker/pull/9882","diff_url":"https://github.com/docker/docker/pull/9882.diff","patch_url":"https://github.com/docker/docker/pull/9882.patch"},"body":"This is yet another meta data PR in an attempt to [pull together](http://xkcd.com/927/) multiple PRs hopefully into something we can get into Docker 1.5 (seriously, let's move fast).\r\n\r\n## Background\r\nSome background... (from what I can gather).  There is currently https://github.com/docker/docker/pull/8955 for adding UserData to a Dockerfile.  Basically it adds the `USERDATA key=value key=\"long value\"` syntax to the Docker.  Then there is https://github.com/docker/docker/pull/9013 which looks to add structured JSON data to a Dockerfile and a container in much the same fashion as Kubernete's annotations.  Finally there is https://github.com/docker/docker/pull/9854 which discusses the need for meta data on container to help with Swarm and similar clustering systems.  There are probably another 10 threads that @thaJeztah can find that also talk about the need to add meta data to containers.\r\n\r\n## We need this...\r\nWe need meta data, it's clear user want it.\r\n\r\n## Labels\r\n\r\nWe already have labels on Hosts (Docker daemon) today.  It seems that going forward we should be able to add labels to everything: Hosts, containers, volumes, images, etc.  Let's just continue with that approach.  Labels are simple key/value pairs in the style of `map[string]string`.  There have been comments to standarize the format of the keys such that we have namespaces or other means to prevent conflicts.  Honestly I don't think that is all that necesary at the Docker level to dictate this.  It's just good practice to namespace things.  Whether you do \"foo_bar\" or \"foo/bar\" or \"com.foo/bar\", who really cares.  If your going to use \"id=3\", well that's a bad name and somebody may clobber your value.  I'm assuming some will disagree with me on this one.  That's fine, I'll agree to a namespace standard just as long as it doesn't take three weeks and 132 comments to decide that DNS format is far superior to arbitrary strings split by \"/\".\r\n\r\nLabels are not structured data, and as such this PR is different from https://github.com/docker/docker/pull/9013, so that discussion can happen differently.  Honestly, I'm not in favor of adding structured data to objects and having Docker maintain it.  But if others disagree, so be it, we can have structured data as something else.\r\n\r\n## What about ENV vars\r\n\r\nYes, labels are very close to environment variables.  You can add ENV to a Dockerfile and you can add them at container create.  The basic difference here is that these key/values are not visible to the running processes in the container.\r\n\r\n## Lookup by Label\r\n\r\nAnother key attribute of labels is that you should be able to find an object based on it's label.  This should initially be kept very simple.  You can either say \"give me all images/containers that have key foo.\"  Or you can say \"give me all images/containers that have foo=bar\".\r\n\r\n## How should we go about doing this?\r\n\r\nI think https://github.com/docker/docker/pull/8955 is the right start.  `USERDATA` should be renamed to `LABEL`.  Now that we have `LABEL` on images we need to add `--label key=value` to `docker run/create`.  This is in the same fashion as `ENV` and `-e` today.\r\n\r\nNow the only thing left do to is to figure out how to query based on labels.  We just need to add `--label foo` or `--label foo=bar` to `docker images/ps`.\r\n\r\n## It's just that simple folks\r\n\r\nOkay, good?  Alright, let's move forward..."},"comment":{"url":"https://api.github.com/repos/docker/docker/issues/comments/69384490","html_url":"https://github.com/docker/docker/pull/9882#issuecomment-69384490","issue_url":"https://api.github.com/repos/docker/docker/issues/9882","id":69384490,"user":{"login":"dreamcat4","id":63074,"avatar_url":"https://avatars.githubusercontent.com/u/63074?v=3","gravatar_id":"","url":"https://api.github.com/users/dreamcat4","html_url":"https://github.com/dreamcat4","followers_url":"https://api.github.com/users/dreamcat4/followers","following_url":"https://api.github.com/users/dreamcat4/following{/other_user}","gists_url":"https://api.github.com/users/dreamcat4/gists{/gist_id}","starred_url":"https://api.github.com/users/dreamcat4/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dreamcat4/subscriptions","organizations_url":"https://api.github.com/users/dreamcat4/orgs","repos_url":"https://api.github.com/users/dreamcat4/repos","events_url":"https://api.github.com/users/dreamcat4/events{/privacy}","received_events_url":"https://api.github.com/users/dreamcat4/received_events","type":"User","site_admin":false},"created_at":"2015-01-09T19:22:44Z","updated_at":"2015-01-09T19:22:44Z","body":"@thaJeztah ah, i now see your original comment near the top where you first mention encoding json into a string value. Sorry I missed that the first time around.\r\n\r\nDon't doubt your assessment about the implementation being harder. I don't think the current proposed version of it needs to be any much different. I am not arguing for that. Just that the name of the feature as `labels`, is a very limiting concept that cannot be expanded upon any further into the future, for subsequent revisions or this feature. It seems shortsighted.\r\n\r\nI do agree that complex search expressions do irk a lot of people. Because they already IRK me too when using complex go templates in `docker inspect --format '{{  arcane go templates one-liner here }}'`.\r\n\r\nWhat if we could eventually turn the problem on it's head? And instead simply converted any non-string objects to their json string representations, before passing them to those newly exposed string matching and search functions? To cache those json blobs representations would improve the speed of successive searching.\r\n\r\nThen they still get handled and output to sstdout as the sort of embedded json strings that you showed me here in your recent example. But critically that their underlying native representation need not be forced to be a string (not right now, but eventually, when the feature is improved upon). For arbitrary structured metadata.\r\n\r\nThe same proposed text search interface(s) would then continue to work externally exactly the same as before. For in the case of complex data the output would be just json blobs for those complex data instead. Sorry. I feel I am repeating myself here.\r\n\r\nIn fig.yml, I need to express arbitrary metadata that is nested. For intro-intra-spection. In docker compose if I follow your solution to my problem then that would mean constructing a pretty horrendous encoded json blob (as per the example given above) and inserting that into a string keys under a `labels:` yaml key for each service i declare in my human-readable yaml files. Never want to be editing json directly in a .yml document. But especially if it is a single-quoted and backslash-escaped json blob. That would be far too error prone."}}