Yeah. Interesting. I get what they are doing with entrypoint vs command,
but it's sort of horribly inconsistent from an end-user POV. For some
containers you have to specify command, but not argv[0], for others you
have to specify a full command with argv.

Is there a common mode we can fall back on? Something like:

if len(container.command) > 0 {
endpoint = container.command[0]
container.command = container.command[1:]
}

I guess that breaks for anyone that relies on entrypoint and adds args to
it.

Uggh. So tacky. Can't we do better?

On Thu, Oct 9, 2014 at 5:17 PM, Johan Euphrosine notifications@github.com
wrote:

https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/api/types.go#L222
doesn't seem to allow it.

Reply to this email directly or view it on GitHub
#1710.

@proppy OOC, what do you want to do that requires overriding the entrypoint of the container?

@thockin In this area, we might as well match Docker's API, IMO.

@bgrant0607 can't really say, that's part of the docker primitive that users can manipulate. Some docker image might expose an entrypoint that you want to override, i.e: add flags to an interpreter or prefix with a debugger.

Can't flags be added without exposing entrypoint?

Common Docker cases like starting a shell or debugger won't even work right now, since we don't have a way to open stdin (#1521).

It depends, flags could be added w/ CMD (which is passed to ENTRYPOINT argv if defined) but it means you have to override the default args that might be embedded in the image metadata.

Docker's API is a mess here, but given that and given that people USE
Docker's messy API, I think we're stuck.

On Fri, Oct 10, 2014 at 10:41 AM, bgrant0607 notifications@github.com
wrote:

@proppy https://github.com/proppy OOC, what do you want to do that
requires overriding the entrypoint of the container?

@thockin https://github.com/thockin In this area, we might as well
match Docker's API, IMO.

Reply to this email directly or view it on GitHub
#1710 (comment)
.

/cc @erictune

Closing in favor of #2316, where all the discussion is happening.