On launching command tasks

[Alex Rukletsov <al...@mesosphere.com>]

When launching a command task without wrapping it in `/bin/sh -c` (i.e.
CommandInfo.shell=false), Mesos expects the first argument to be the same
as the command itself [1]. Though this is similar to how UNIX exec* calls
operate, it can be unclear to a user. Moreover, we do not validate this on
the master side, but rather let the command executor crash with a "bad
address" error. Docker, for example, requires the command only once in
their entrypoint specification [2].

My suggestion is to change the command executor so that it ensures that the
first argument is always the command itself.

Alternatively, if we prefer to keep the current behaviour, I would propose
to adjust the documentation to be more explicit and introduce a validation
check on the master.

[1] Example snippet in C++

   commandInfo->set_value(command);

   commandInfo->add_arguments()->assign(command);


[2] https://docs.docker.com/engine/reference/builder/#entrypoint

Re: On launching command tasks

[Alex Rukletsov <al...@mesosphere.com>]

Connor,

this is also fine and improves current behaviour.

On Sat, Apr 9, 2016 at 10:52 PM, <co...@gmail.com> wrote:

> Hi Alex, inline.
>
> > On Apr 9, 2016, at 12:00, Alex Rukletsov <al...@mesosphere.com> wrote:
> >
> > if `shell` is false and `argv.size` is
> > 0, assign command to `argv[0]`?
>
> Instead of trying to fix the TaskInfo on behalf of the framework, maybe it
> would be more transparent to preemptively fail the task with TASK_ERROR in
> this case?
>
> > On Sat, Apr 9, 2016 at 2:59 AM, Benjamin Mahler <bm...@apache.org>
> wrote:
> >
> >>>
> >>> Mesos expects the first argument to be the same
> >>> as the command itself [1]
> >>
> >>
> >> To be precise, what does "expect" mean here? Do we actually have code in
> >> mesos with this expectation? Or are you just saying that we require
> >> CommandInfo.arguments to map directly to exec's 'args'?
> >>
> >> Have you considered why exec has this API? It looks like there are some
> use
> >> cases for not just using the filename as argv[0]?
> >>
> >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
> (see
> >> Rationale)
> >>
> >>> The requirement on a Strictly Conforming POSIX Application also states
> >>> that the value passed as the first argument be a filename string
> >> associated
> >>> with the process being started. Although some existing applications
> pass
> >> a
> >>> pathname rather than a filename string in some circumstances, a
> filename
> >>> string is more generally useful, since the common usage of argv[0] is
> in
> >>> printing diagnostics. In some cases the filename passed is not the
> actual
> >>> filename of the file; for example, many implementations of the login
> >>> utility use a convention of prefixing a <hyphen> ( '-' ) to the actual
> >>> filename, which indicates to the command interpreter being invoked that
> >> it
> >>> is a "login shell".
> >>
> >>
> >>> On Sat, Apr 2, 2016 at 7:14 AM, Guangya Liu <gy...@gmail.com>
> wrote:
> >>>
> >>> +1 on using docker mode, this can help the framework developer.
> >>>
> >>> Setting the command twice can sometimes make people confused. When I
> was
> >>> working for the patch https://reviews.apache.org/r/44441/ , I was
> also a
> >>> bit confused before go through the code in agent part.
> >>>
> >>>
> >>>
> >>>> On Sat, Apr 2, 2016 at 1:17 AM, haosdent <ha...@gmail.com> wrote:
> >>>>
> >>>> +1 For follow Docker behaviour, it is inconvenient to write the
> command
> >>>> twice.
> >>>>
> >>>> On Fri, Apr 1, 2016 at 10:12 PM, Alex Rukletsov <al...@mesosphere.com>
> >>>> wrote:
> >>>>
> >>>>> When launching a command task without wrapping it in `/bin/sh -c`
> >> (i.e.
> >>>>> CommandInfo.shell=false), Mesos expects the first argument to be the
> >>> same
> >>>>> as the command itself [1]. Though this is similar to how UNIX exec*
> >>> calls
> >>>>> operate, it can be unclear to a user. Moreover, we do not validate
> >> this
> >>>> on
> >>>>> the master side, but rather let the command executor crash with a
> >> "bad
> >>>>> address" error. Docker, for example, requires the command only once
> >> in
> >>>>> their entrypoint specification [2].
> >>>>>
> >>>>> My suggestion is to change the command executor so that it ensures
> >> that
> >>>> the
> >>>>> first argument is always the command itself.
> >>>>>
> >>>>> Alternatively, if we prefer to keep the current behaviour, I would
> >>>> propose
> >>>>> to adjust the documentation to be more explicit and introduce a
> >>>> validation
> >>>>> check on the master.
> >>>>>
> >>>>> [1] Example snippet in C++
> >>>>>
> >>>>>   commandInfo->set_value(command);
> >>>>>
> >>>>>   commandInfo->add_arguments()->assign(command);
> >>>>>
> >>>>>
> >>>>> [2] https://docs.docker.com/engine/reference/builder/#entrypoint
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Best Regards,
> >>>> Haosdent Huang
> >>
>

Re: On launching command tasks

[co...@gmail.com]

Hi Alex, inline.

> On Apr 9, 2016, at 12:00, Alex Rukletsov <al...@mesosphere.com> wrote:
> 
> if `shell` is false and `argv.size` is
> 0, assign command to `argv[0]`?

Instead of trying to fix the TaskInfo on behalf of the framework, maybe it would be more transparent to preemptively fail the task with TASK_ERROR in this case?

> On Sat, Apr 9, 2016 at 2:59 AM, Benjamin Mahler <bm...@apache.org> wrote:
> 
>>> 
>>> Mesos expects the first argument to be the same
>>> as the command itself [1]
>> 
>> 
>> To be precise, what does "expect" mean here? Do we actually have code in
>> mesos with this expectation? Or are you just saying that we require
>> CommandInfo.arguments to map directly to exec's 'args'?
>> 
>> Have you considered why exec has this API? It looks like there are some use
>> cases for not just using the filename as argv[0]?
>> 
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html (see
>> Rationale)
>> 
>>> The requirement on a Strictly Conforming POSIX Application also states
>>> that the value passed as the first argument be a filename string
>> associated
>>> with the process being started. Although some existing applications pass
>> a
>>> pathname rather than a filename string in some circumstances, a filename
>>> string is more generally useful, since the common usage of argv[0] is in
>>> printing diagnostics. In some cases the filename passed is not the actual
>>> filename of the file; for example, many implementations of the login
>>> utility use a convention of prefixing a <hyphen> ( '-' ) to the actual
>>> filename, which indicates to the command interpreter being invoked that
>> it
>>> is a "login shell".
>> 
>> 
>>> On Sat, Apr 2, 2016 at 7:14 AM, Guangya Liu <gy...@gmail.com> wrote:
>>> 
>>> +1 on using docker mode, this can help the framework developer.
>>> 
>>> Setting the command twice can sometimes make people confused. When I was
>>> working for the patch https://reviews.apache.org/r/44441/ , I was also a
>>> bit confused before go through the code in agent part.
>>> 
>>> 
>>> 
>>>> On Sat, Apr 2, 2016 at 1:17 AM, haosdent <ha...@gmail.com> wrote:
>>>> 
>>>> +1 For follow Docker behaviour, it is inconvenient to write the command
>>>> twice.
>>>> 
>>>> On Fri, Apr 1, 2016 at 10:12 PM, Alex Rukletsov <al...@mesosphere.com>
>>>> wrote:
>>>> 
>>>>> When launching a command task without wrapping it in `/bin/sh -c`
>> (i.e.
>>>>> CommandInfo.shell=false), Mesos expects the first argument to be the
>>> same
>>>>> as the command itself [1]. Though this is similar to how UNIX exec*
>>> calls
>>>>> operate, it can be unclear to a user. Moreover, we do not validate
>> this
>>>> on
>>>>> the master side, but rather let the command executor crash with a
>> "bad
>>>>> address" error. Docker, for example, requires the command only once
>> in
>>>>> their entrypoint specification [2].
>>>>> 
>>>>> My suggestion is to change the command executor so that it ensures
>> that
>>>> the
>>>>> first argument is always the command itself.
>>>>> 
>>>>> Alternatively, if we prefer to keep the current behaviour, I would
>>>> propose
>>>>> to adjust the documentation to be more explicit and introduce a
>>>> validation
>>>>> check on the master.
>>>>> 
>>>>> [1] Example snippet in C++
>>>>> 
>>>>>   commandInfo->set_value(command);
>>>>> 
>>>>>   commandInfo->add_arguments()->assign(command);
>>>>> 
>>>>> 
>>>>> [2] https://docs.docker.com/engine/reference/builder/#entrypoint
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Best Regards,
>>>> Haosdent Huang
>> 

Re: On launching command tasks

[Alex Rukletsov <al...@mesosphere.com>]

Under "expect" I meant that Mesos expects users to set
CommandInfo.arguments in a way `exec` does not error out. I'm an ESL, but I
would have used "require" if we had validation in place. We don't, and I
find this unfortunate. I see why one may want to set argv[0] to a value
different from the command, but I'm not sure to what extent it applies to
Mesos context. Moreover, the `exec` design seems a bit unfortunate to me
and I'm not yet convinced we should repeat it in the Mesos API.

Since my concern is mostly a "bad address" crash if CommandInfo.arguments
are empty while CommandInfo.shell is false, how about updating the command
executor to address only this case: if `shell` is false and `argv.size` is
0, assign command to `argv[0]`?

On Sat, Apr 9, 2016 at 2:59 AM, Benjamin Mahler <bm...@apache.org> wrote:

> >
> > Mesos expects the first argument to be the same
> > as the command itself [1]
>
>
> To be precise, what does "expect" mean here? Do we actually have code in
> mesos with this expectation? Or are you just saying that we require
> CommandInfo.arguments to map directly to exec's 'args'?
>
> Have you considered why exec has this API? It looks like there are some use
> cases for not just using the filename as argv[0]?
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html (see
> Rationale)
>
> > The requirement on a Strictly Conforming POSIX Application also states
> > that the value passed as the first argument be a filename string
> associated
> > with the process being started. Although some existing applications pass
> a
> > pathname rather than a filename string in some circumstances, a filename
> > string is more generally useful, since the common usage of argv[0] is in
> > printing diagnostics. In some cases the filename passed is not the actual
> > filename of the file; for example, many implementations of the login
> > utility use a convention of prefixing a <hyphen> ( '-' ) to the actual
> > filename, which indicates to the command interpreter being invoked that
> it
> > is a "login shell".
>
>
> On Sat, Apr 2, 2016 at 7:14 AM, Guangya Liu <gy...@gmail.com> wrote:
>
> > +1 on using docker mode, this can help the framework developer.
> >
> > Setting the command twice can sometimes make people confused. When I was
> > working for the patch https://reviews.apache.org/r/44441/ , I was also a
> > bit confused before go through the code in agent part.
> >
> >
> >
> > On Sat, Apr 2, 2016 at 1:17 AM, haosdent <ha...@gmail.com> wrote:
> >
> > > +1 For follow Docker behaviour, it is inconvenient to write the command
> > > twice.
> > >
> > > On Fri, Apr 1, 2016 at 10:12 PM, Alex Rukletsov <al...@mesosphere.com>
> > > wrote:
> > >
> > > > When launching a command task without wrapping it in `/bin/sh -c`
> (i.e.
> > > > CommandInfo.shell=false), Mesos expects the first argument to be the
> > same
> > > > as the command itself [1]. Though this is similar to how UNIX exec*
> > calls
> > > > operate, it can be unclear to a user. Moreover, we do not validate
> this
> > > on
> > > > the master side, but rather let the command executor crash with a
> "bad
> > > > address" error. Docker, for example, requires the command only once
> in
> > > > their entrypoint specification [2].
> > > >
> > > > My suggestion is to change the command executor so that it ensures
> that
> > > the
> > > > first argument is always the command itself.
> > > >
> > > > Alternatively, if we prefer to keep the current behaviour, I would
> > > propose
> > > > to adjust the documentation to be more explicit and introduce a
> > > validation
> > > > check on the master.
> > > >
> > > > [1] Example snippet in C++
> > > >
> > > >    commandInfo->set_value(command);
> > > >
> > > >    commandInfo->add_arguments()->assign(command);
> > > >
> > > >
> > > > [2] https://docs.docker.com/engine/reference/builder/#entrypoint
> > > >
> > >
> > >
> > >
> > > --
> > > Best Regards,
> > > Haosdent Huang
> > >
> >
>

Re: On launching command tasks

[Benjamin Mahler <bm...@apache.org>]

>
> Mesos expects the first argument to be the same
> as the command itself [1]


To be precise, what does "expect" mean here? Do we actually have code in
mesos with this expectation? Or are you just saying that we require
CommandInfo.arguments to map directly to exec's 'args'?

Have you considered why exec has this API? It looks like there are some use
cases for not just using the filename as argv[0]?

http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html (see
Rationale)

> The requirement on a Strictly Conforming POSIX Application also states
> that the value passed as the first argument be a filename string associated
> with the process being started. Although some existing applications pass a
> pathname rather than a filename string in some circumstances, a filename
> string is more generally useful, since the common usage of argv[0] is in
> printing diagnostics. In some cases the filename passed is not the actual
> filename of the file; for example, many implementations of the login
> utility use a convention of prefixing a <hyphen> ( '-' ) to the actual
> filename, which indicates to the command interpreter being invoked that it
> is a "login shell".


On Sat, Apr 2, 2016 at 7:14 AM, Guangya Liu <gy...@gmail.com> wrote:

> +1 on using docker mode, this can help the framework developer.
>
> Setting the command twice can sometimes make people confused. When I was
> working for the patch https://reviews.apache.org/r/44441/ , I was also a
> bit confused before go through the code in agent part.
>
>
>
> On Sat, Apr 2, 2016 at 1:17 AM, haosdent <ha...@gmail.com> wrote:
>
> > +1 For follow Docker behaviour, it is inconvenient to write the command
> > twice.
> >
> > On Fri, Apr 1, 2016 at 10:12 PM, Alex Rukletsov <al...@mesosphere.com>
> > wrote:
> >
> > > When launching a command task without wrapping it in `/bin/sh -c` (i.e.
> > > CommandInfo.shell=false), Mesos expects the first argument to be the
> same
> > > as the command itself [1]. Though this is similar to how UNIX exec*
> calls
> > > operate, it can be unclear to a user. Moreover, we do not validate this
> > on
> > > the master side, but rather let the command executor crash with a "bad
> > > address" error. Docker, for example, requires the command only once in
> > > their entrypoint specification [2].
> > >
> > > My suggestion is to change the command executor so that it ensures that
> > the
> > > first argument is always the command itself.
> > >
> > > Alternatively, if we prefer to keep the current behaviour, I would
> > propose
> > > to adjust the documentation to be more explicit and introduce a
> > validation
> > > check on the master.
> > >
> > > [1] Example snippet in C++
> > >
> > >    commandInfo->set_value(command);
> > >
> > >    commandInfo->add_arguments()->assign(command);
> > >
> > >
> > > [2] https://docs.docker.com/engine/reference/builder/#entrypoint
> > >
> >
> >
> >
> > --
> > Best Regards,
> > Haosdent Huang
> >
>

Re: On launching command tasks

[Guangya Liu <gy...@gmail.com>]

+1 on using docker mode, this can help the framework developer.

Setting the command twice can sometimes make people confused. When I was
working for the patch https://reviews.apache.org/r/44441/ , I was also a
bit confused before go through the code in agent part.



On Sat, Apr 2, 2016 at 1:17 AM, haosdent <ha...@gmail.com> wrote:

> +1 For follow Docker behaviour, it is inconvenient to write the command
> twice.
>
> On Fri, Apr 1, 2016 at 10:12 PM, Alex Rukletsov <al...@mesosphere.com>
> wrote:
>
> > When launching a command task without wrapping it in `/bin/sh -c` (i.e.
> > CommandInfo.shell=false), Mesos expects the first argument to be the same
> > as the command itself [1]. Though this is similar to how UNIX exec* calls
> > operate, it can be unclear to a user. Moreover, we do not validate this
> on
> > the master side, but rather let the command executor crash with a "bad
> > address" error. Docker, for example, requires the command only once in
> > their entrypoint specification [2].
> >
> > My suggestion is to change the command executor so that it ensures that
> the
> > first argument is always the command itself.
> >
> > Alternatively, if we prefer to keep the current behaviour, I would
> propose
> > to adjust the documentation to be more explicit and introduce a
> validation
> > check on the master.
> >
> > [1] Example snippet in C++
> >
> >    commandInfo->set_value(command);
> >
> >    commandInfo->add_arguments()->assign(command);
> >
> >
> > [2] https://docs.docker.com/engine/reference/builder/#entrypoint
> >
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: On launching command tasks

[haosdent <ha...@gmail.com>]

+1 For follow Docker behaviour, it is inconvenient to write the command
twice.

On Fri, Apr 1, 2016 at 10:12 PM, Alex Rukletsov <al...@mesosphere.com> wrote:

> When launching a command task without wrapping it in `/bin/sh -c` (i.e.
> CommandInfo.shell=false), Mesos expects the first argument to be the same
> as the command itself [1]. Though this is similar to how UNIX exec* calls
> operate, it can be unclear to a user. Moreover, we do not validate this on
> the master side, but rather let the command executor crash with a "bad
> address" error. Docker, for example, requires the command only once in
> their entrypoint specification [2].
>
> My suggestion is to change the command executor so that it ensures that the
> first argument is always the command itself.
>
> Alternatively, if we prefer to keep the current behaviour, I would propose
> to adjust the documentation to be more explicit and introduce a validation
> check on the master.
>
> [1] Example snippet in C++
>
>    commandInfo->set_value(command);
>
>    commandInfo->add_arguments()->assign(command);
>
>
> [2] https://docs.docker.com/engine/reference/builder/#entrypoint
>



-- 
Best Regards,
Haosdent Huang