{"action":"created","issue":{"url":"https://api.github.com/repos/opencontainers/image-spec/issues/443","repository_url":"https://api.github.com/repos/opencontainers/image-spec","labels_url":"https://api.github.com/repos/opencontainers/image-spec/issues/443/labels{/name}","comments_url":"https://api.github.com/repos/opencontainers/image-spec/issues/443/comments","events_url":"https://api.github.com/repos/opencontainers/image-spec/issues/443/events","html_url":"https://github.com/opencontainers/image-spec/issues/443","id":187192937,"number":443,"title":"Volume mountpoints should have additional flags","user":{"login":"vishvananda","id":142222,"avatar_url":"https://avatars.githubusercontent.com/u/142222?v=3","gravatar_id":"","url":"https://api.github.com/users/vishvananda","html_url":"https://github.com/vishvananda","followers_url":"https://api.github.com/users/vishvananda/followers","following_url":"https://api.github.com/users/vishvananda/following{/other_user}","gists_url":"https://api.github.com/users/vishvananda/gists{/gist_id}","starred_url":"https://api.github.com/users/vishvananda/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vishvananda/subscriptions","organizations_url":"https://api.github.com/users/vishvananda/orgs","repos_url":"https://api.github.com/users/vishvananda/repos","events_url":"https://api.github.com/users/vishvananda/events{/privacy}","received_events_url":"https://api.github.com/users/vishvananda/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/opencontainers/image-spec/milestones/4","html_url":"https://github.com/opencontainers/image-spec/milestones/post-v1.0.0","labels_url":"https://api.github.com/repos/opencontainers/image-spec/milestones/4/labels","id":1707835,"number":4,"title":"post-v1.0.0","description":"","creator":{"login":"philips","id":33544,"avatar_url":"https://avatars.githubusercontent.com/u/33544?v=3","gravatar_id":"","url":"https://api.github.com/users/philips","html_url":"https://github.com/philips","followers_url":"https://api.github.com/users/philips/followers","following_url":"https://api.github.com/users/philips/following{/other_user}","gists_url":"https://api.github.com/users/philips/gists{/gist_id}","starred_url":"https://api.github.com/users/philips/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/philips/subscriptions","organizations_url":"https://api.github.com/users/philips/orgs","repos_url":"https://api.github.com/users/philips/repos","events_url":"https://api.github.com/users/philips/events{/privacy}","received_events_url":"https://api.github.com/users/philips/received_events","type":"User","site_admin":false},"open_issues":13,"closed_issues":6,"state":"open","created_at":"2016-04-14T22:26:30Z","updated_at":"2016-11-16T22:25:26Z","due_on":null,"closed_at":null},"comments":5,"created_at":"2016-11-03T21:18:20Z","updated_at":"2016-11-19T18:53:17Z","closed_at":null,"body":"Volume mountpoints in a container should have data explaining how they are used to help runtimes decide what should be done with them. The first and most obvious is a \"readonly\" boolean. There are a couple other flags which also could be useful.\r\n\r\n```\r\nreadonly:\r\n  true if the container only needs to read from the mountpoint (generally implemented by mounting a readonly volume)\r\n  example: directory for process config files\r\ntemporary:\r\n  true if the volume should be cleared between runs of the container process (generally implemented by mounting a tmpfs)\r\n  example: directory for pid files or secrets that only exist for the current run of the process\r\ndata:\r\n  true if the image has data in this directory that can be used to initialize the volume (generally implemented by copying data out of the container when creating the volume)\r\n  example: directory with an initial database\r\n```\r\n\r\nThe purpose of these flags might be illustrated with an example. Lets say I'm making a mysql container. I might have the following mountpoints defined:\r\n\r\n```\r\n\"volumes\": [\r\n  # config files\r\n  {\"name\": \"config\",\r\n   \"path\": \"/etc/mysql\",\r\n   \"readonly\": true, # config should be modified from the outside\r\n   \"data\": true}, # because the default config lives here\r\n  # pid files\r\n  {\"name\": \"run\",\r\n   \"path\": \"/var/run/mysql\",\r\n   \"temporary\": true}, # for the pid file\r\n  # uds socket\r\n  {\"name\": \"tmp\",\r\n   \"path\": \"/tmp\",\r\n   \"temporary\": true}, # for the mysql socket file \r\n  # db files\r\n  {\"name\": \"db\",\r\n   \"path\": \"/var/lib/mysql\",\r\n   \"data\": true}, # because a default db exists here\r\n  # log files\r\n  {\"name\": \"log\",\r\n   \"path\": \"/var/log/mysql\"},\r\n]\r\n```\r\n\r\nClearly some of these could be consolidated using symlinks (tmp and run could share the same dir, as well as db and logs), but I wanted to give a verbose description.\r\n"},"comment":{"url":"https://api.github.com/repos/opencontainers/image-spec/issues/comments/261732239","html_url":"https://github.com/opencontainers/image-spec/issues/443#issuecomment-261732239","issue_url":"https://api.github.com/repos/opencontainers/image-spec/issues/443","id":261732239,"user":{"login":"vishvananda","id":142222,"avatar_url":"https://avatars.githubusercontent.com/u/142222?v=3","gravatar_id":"","url":"https://api.github.com/users/vishvananda","html_url":"https://github.com/vishvananda","followers_url":"https://api.github.com/users/vishvananda/followers","following_url":"https://api.github.com/users/vishvananda/following{/other_user}","gists_url":"https://api.github.com/users/vishvananda/gists{/gist_id}","starred_url":"https://api.github.com/users/vishvananda/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vishvananda/subscriptions","organizations_url":"https://api.github.com/users/vishvananda/orgs","repos_url":"https://api.github.com/users/vishvananda/repos","events_url":"https://api.github.com/users/vishvananda/events{/privacy}","received_events_url":"https://api.github.com/users/vishvananda/received_events","type":"User","site_admin":false},"created_at":"2016-11-19T18:53:17Z","updated_at":"2016-11-19T18:53:17Z","body":"> Volumes really only specifies what could be considered \"ephemeral\" locations. There are implications to how mounts and volume declarations would interact that may result in odd behavior.\r\n\r\n> Allowing the image to name volumes will lead to security problems in systems that have a single volume namespace or overlap in volume names within a namespace (imagine a malicious container that wants to mount the log volume and read your logs).\r\n\r\nI'm not sure I follow your logic here. I'm not suggesting the image spec defines anything about what the runtime names the volumes. My goal here is for the builder of the image to specify locations in the image filesystem that represent a interfaces (either input-->config or output-->logs). The current definition is not rich enough. Either we need to put enough information into the image-spec so that a runtime could determine how to set up mounts properly, or (as @wking suggests) we allow a runtime spec to be shipped.\r\n\r\nI personally like the separation between `Binds` defined by the image-spec and `Mounts` defined by the runtime-spec, but the Bind needs some hints to tell the runtime how the mount is going to be used. For example if the bind has configuration data, then the runtime likely wants to copy the data out into the volume it creates, and the mount should be read-only.\r\n\r\n> The other issue with such a design is that booleans without considering mutual exclusion create a number of combinations that don't make a lot of sense. As you add more booleans, the space of invalid option combinations increases. For example, what is the use of a temporary, readonly volume with data=false? What if the temporary space is required but a tmpfs won't provide enough storage (these are really \"ephemeral\", rather than tmpfs)?\r\n\r\nI agree that a list of booleans might not be the best description, maybe we define a simple enum that describes how the volume should be used.\r\n\r\n```\r\nBindType {\r\n  Config --> runtime could implement with copy out and read-only mount\r\n  Tmp --> runtime could implement with tmpfs\r\n  Data --> runtime could implement with a r/w volume\r\n}\r\n```\r\n\r\nIf we don't think that we can agree on a common set of bind types, then it probably would be enough to allow some arbitrary metadata in the Bind (or as it is currently written: Volume) definition."}}
{"actor":{"display_login":"vishvananda"}}