{"action":"created","issue":{"url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/issues/2316","labels_url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/issues/2316/labels{/name}","comments_url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/issues/2316/comments","events_url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/issues/2316/events","html_url":"https://github.com/GoogleCloudPlatform/kubernetes/issues/2316","id":48467938,"number":2316,"title":"Images with ENTRYPOINT set can't expand environment variables in command","user":{"login":"smarterclayton","id":1163175,"avatar_url":"https://avatars.githubusercontent.com/u/1163175?v=3","gravatar_id":"","url":"https://api.github.com/users/smarterclayton","html_url":"https://github.com/smarterclayton","followers_url":"https://api.github.com/users/smarterclayton/followers","following_url":"https://api.github.com/users/smarterclayton/following{/other_user}","gists_url":"https://api.github.com/users/smarterclayton/gists{/gist_id}","starred_url":"https://api.github.com/users/smarterclayton/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/smarterclayton/subscriptions","organizations_url":"https://api.github.com/users/smarterclayton/orgs","repos_url":"https://api.github.com/users/smarterclayton/repos","events_url":"https://api.github.com/users/smarterclayton/events{/privacy}","received_events_url":"https://api.github.com/users/smarterclayton/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/labels/api%2Fcluster","name":"api/cluster","color":"e1ed21"},{"url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/labels/area%2Fusability","name":"area/usability","color":"00cc00"},{"url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/labels/kind%2Fenhancement","name":"kind/enhancement","color":"84b6eb"},{"url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/labels/priority%2FP2","name":"priority/P2","color":"fbca04"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2014-11-12T03:19:27Z","updated_at":"2015-01-13T23:18:54Z","closed_at":null,"body":"To expand environment variables, the command for a pod must use `sh` - `command: [\"sh\", \"-c\", \"${MYVAR}\"]`.  However, images with an entrypoint will not be able to use this technique, because the command array is then appended to the ENTRYPOINT instead of replacing the CMD.\r\n\r\nSaying that images with entry points can't do variable expansion seems too limiting.  We have no technique to allow a consumer to solve that problem.  Assuming that entrypoint is here to stay and an image consumer may want to either replace variables OR override the entrypoint, there are a few options:\r\n\r\n1. Allow a command to specify it should be expanded prior to execution.  Won't allow environment in the image to take effect unless we load it by introspecting the image and emulating environment support.  Will not catch ~/.bash_profile settings?\r\n2. Allow a command to be specified as a shell call, and concatenate it into a string before invoking docker.  Probably not safe, and breaks argument encapsulation (we'd have to safe shell quote).\r\n3. When command is specified, bypass entrypoint totally.  Breaks existing users who depend on arguments.  Prevents image consumers from letting the image define its default behavior and specify arguments.\r\n a. Add an option to command to treat the command as an override to entrypoint. Backwards compatible.\r\n b. Add a fake environment var to be evaluated prior to container start that substitutes the images entrypoint (`command: ['sh', '-c', '${ENTRYPOINT}', ...]')\r\n4. Add an option to command which prepends \"sh\" \"-c\".  Not guaranteed to work, not all images have \"sh\" or may have nonstandard shell paths.\r\n\r\n3 seems the most consistent (don't allow entry points) with the minor inconvenience of ignoring the preferred path of the image author.  3a seems crufty.  3b is very crufty.  1, 2, and 4 seem very crufty."},"comment":{"url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/issues/comments/69841063","html_url":"https://github.com/GoogleCloudPlatform/kubernetes/issues/2316#issuecomment-69841063","issue_url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/issues/2316","id":69841063,"user":{"login":"thockin","id":5595220,"avatar_url":"https://avatars.githubusercontent.com/u/5595220?v=3","gravatar_id":"","url":"https://api.github.com/users/thockin","html_url":"https://github.com/thockin","followers_url":"https://api.github.com/users/thockin/followers","following_url":"https://api.github.com/users/thockin/following{/other_user}","gists_url":"https://api.github.com/users/thockin/gists{/gist_id}","starred_url":"https://api.github.com/users/thockin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/thockin/subscriptions","organizations_url":"https://api.github.com/users/thockin/orgs","repos_url":"https://api.github.com/users/thockin/repos","events_url":"https://api.github.com/users/thockin/events{/privacy}","received_events_url":"https://api.github.com/users/thockin/received_events","type":"User","site_admin":false},"created_at":"2015-01-13T23:18:54Z","updated_at":"2015-01-13T23:18:54Z","body":"On Tue, Jan 13, 2015 at 12:15 PM, bgrant0607 <notifications@github.com> wrote:\r\n>\r\n> Related: Users find it confusing for command to be an array, or at least only an array.\r\n>\r\n> Docker supports:\r\n>\r\n> Cmd - Command to run specified as a string or an array of strings.\r\n> Entrypoint - Set the entrypoint for the container a a string or an array of strings\r\n>\r\n> Do they really support two different json data types using the same field names? We shouldn't do that, but I do think we need to make this easier to use. I could imagine supporting argv (array), command (string), and overrideContainerCommand (bool that indicates the entrypoint string should be set instead of cmd).\r\n\r\nThey really do support 3 different ways to specify commands, and no\r\nreally clear way to differentiate.\r\n\r\nI can see us accepting []string or string for command (not that hard\r\nto implement) since we pass it straight through to docker (though we\r\nshould look at what they actually do with it).  This is, IMO, a bit of\r\nan api disaster.\r\n\r\nI don't see a way for us to override Docker's entrypoint without a\r\ncorresponding entrypoint field in our API.  It's a mess, but there are\r\ncontainers out there that set the entrypoint.\r\n\r\n> If the user wants control over which shell to invoke, they always should have the option of /bin/sh -c ...\r\n\r\nIMO this should ALWAYS have been the API.\r\n\r\n> Kubelet should be able to inspect the container image to determine whether /bin/sh exists. If it doesn't, there are 2 options: (1) fail and generate an event that indicates permanent failure, or (2) bind-mount a shell into the container.\r\n\r\nI think (2) is dubious, and (1) is unneeded.  Just pass it in and fail\r\nif there is no shell?"}}