Open tdooner opened 9 years ago
@tdooner in container jobs, arguments should be used with entrypoint. Command didn't concat with arguments.
@gomes I don't understand?
Are you suggesting I shouldn't use the command field? That doesn't work -- chronos 500's when I post the new configuration.
And there's an issue for that: #544.
I am observing a similar behavior when trying to schedule a Chronos Docker job that has its ENTRYPOINT
set to a particular binary and expects a flag like -foo <option>
. My understanding is that a Chronos configuration containing the fields
{
"command": "",
"arguments": ["-foo", "bar"],
}
should cause the container to be invoked with docker run -foo bar
. What I see though is that the bar
flag option is not passed to the container. The arguments on the Docker container look wrong:
"Args": [
" -foo bar",
"-foo",
"bar"
],
Am I holding it wrong or is this use case really broken since at least October 2015?
I am hitting the same problem, and actually am a little scared that nobody has still addressed the issue...
any progress on this?
Hello, I have tried a few things now, and cannot get the common
exec "$@"
docker entrypoint pattern to work with chronos.To illustrate what I mean, consider this simple entrypoint script:
My reading of http://mesos.github.io/chronos/docs/api.html#job-configuration indicates that if I use configuration containing:
Then I would expect the equivalent of
docker run [image] echo hi
, which according todocker inspect
has"Args": ["echo", "hi"]
. With thisdocker run
command, the entrypoint script works as intended.However, this is not what I observe happening when my job is started via chronos/mesos:
With this configuration, bash is unable to exec an executable named
echo hi
.I don't understand why the arguments are appended to the command string in the first array position and then also appended to the array. Here's the full job configuration. I'm on Chronos 2.4.0 and Mesos 0.23.0. Is there any way around this behavior?
Thanks.