Mailing-List: contact dev-help@mesos.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mesos.apache.org
MIME-Version: 1.0
References: <CANntcz7P3NfxbeXo5cOi8tgdF5_0iUE=9k8BxZUgbfJ3VDPApQ@mail.gmail.com>
 <CAFt=RONWcd=EhyipzAw8=6iqYwCA-H0PQmOj+qP4mGDSQAodQw@mail.gmail.com>
 <CAM+cpfcM6RUbdOqDocnXVfGVJATrXaD3_kg5C=hjzNb6sExmBQ@mail.gmail.com>
 <CAKgKkU51H2ojJdNTG-hnFaJ4aKnoa0vYEYgMxQNoe5OeoYzOpQ@mail.gmail.com> <CAM+cpfc9VBho9Uuh-4AitWP3g1_4c-XbTuFYi=_qPeWR5U8KOw@mail.gmail.com>
In-Reply-To: <CAM+cpfc9VBho9Uuh-4AitWP3g1_4c-XbTuFYi=_qPeWR5U8KOw@mail.gmail.com>
From: David Greenberg <dsg123456789@gmail.com>
Date: Wed, 02 Nov 2016 21:55:37 +0000
Message-ID: <CAA6W+3QQqCAo8Cqu9QJYmcfg+MuLB=pWnzeWQkuVOh-HLaTSHw@mail.gmail.com>
Subject: Re: Allowing both CommandInfo and ExecutorInfo on TaskInfo
To: mesos <dev@mesos.apache.org>
Content-Type: multipart/alternative; boundary=001a114286e4f2929c05405880fc
archived-at: Wed, 02 Nov 2016 21:55:55 -0000

--001a114286e4f2929c05405880fc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I have worked with executors that perform both conditional & unconditional
execution of a process graph, configurable by the framework. I think that
it would be hard to standardize.

On Wed, Nov 2, 2016 at 2:49 PM Zameer Manji <zmanji@apache.org> wrote:

> Joris,
>
> You make a good point. However, I'm not convinced that `CommandInfo` shou=
ld
> be the well defined construct that people use. Can you please describe
> different custom executors, and the overlap between them and how
> CommandInfo will reduce that overlap? I'm having a hard time seeing where
> CommandInfo will solve all of their cases.
>
> Consider the cause of Thermos (Aurora's Executor), it could never use a
> `CommandInfo` struct because it executes a processes graph instead of a
> single command.
>
> If the project wants to go down this path, I think generalizing
> `CommandInfo` that could capture more cases (ie multiple commands or a
> graph of commands) would be a better first step.
>
> What do you think?
>
> On Wed, Oct 26, 2016 at 10:38 AM, Joris Van Remoortere <
> joris@mesosphere.io>
> wrote:
>
> > I do think it would be valuable to have a more well defined contract
> > between frameworks and custom executors.
> >
> > As Zameer pointed out a specific framework and accompanying custom
> executor
> > can decide to do that in the data bytes; however, if we started buildin=
g
> > out a few different flavors of executors then it would be great for the=
re
> > to be standard way to pass command information to them.
> >
> > The current model works well in a 1-1 mapping between framework and
> > executor binaries. In a world where that is 1-N it means all N executor=
s
> > have to use the same method of passing the command.
> >
> > =E2=80=94
> > *Joris Van Remoortere*
> > Mesosphere
> >
> > On Mon, Oct 17, 2016 at 4:25 PM, Zameer Manji <zmanji@apache.org> wrote=
:
> >
> > > I'm not convinced this is a valid use case.
> > >
> > > Mesos is supposed to be a generic kernel for launching "tasks",
> whatever
> > > they might be.
> > >
> > > In some cases it is useful to launch an executable, in other cases it
> > might
> > > be useful to launch a series of executables, and in some other cases =
it
> > > might be useful to spawn a thread to do some work. Whatever that migh=
t
> > be,
> > > it doesn't matter to Mesos and the executor and framework are free to
> > > establish a contract in `ExecutorInfo.data`, completely independent o=
f
> > the
> > > Mesos API.
> > >
> > > I think formalizing this contract between executors and frameworks vi=
a
> > > CommandInfo is going to introduce more problems than what they solve.
> If
> > > the CommandInfo struct is useful, frameworks and executors can just
> stuff
> > > that into ExecutorInfo.data, however it's not something that they nee=
d
> to
> > > adhere too.
> > >
> > > What's the underlying motivation for this?
> > >
> > >
> > >
> > > On Thu, Oct 13, 2016 at 10:40 AM, haosdent <haosdent@gmail.com> wrote=
:
> > >
> > > > For command task, if its `ExecutorInfo` would set with
> > `CommandExecutor`
> > > as
> > > > well?
> > > >
> > > > Some tickets may relate to this.
> > > >
> > > > [1]: https://issues.apache.org/jira/browse/MESOS-2330
> > > > [2]: https://issues.apache.org/jira/browse/MESOS-527
> > > > [3]: https://issues.apache.org/jira/browse/MESOS-5198
> > > >
> > > > On Fri, Oct 14, 2016 at 1:00 AM, Vinod Kone <vinodkone@apache.org>
> > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > We are contemplating whether to allow both CommandInfo and
> > ExecutorInfo
> > > > on
> > > > > TaskInfo (MESOS-6294 <https://issues.apache.org/
> > jira/browse/MESOS-6294
> > > > >).
> > > > > Currently we only allow one or the other. The motivation is to
> allow
> > > > custom
> > > > > executors a more structured way to pass information (e.g, command=
)
> > > about
> > > > > Task. Right now custom executors have to get this data via
> > > > `TaskInfo.bytes`
> > > > > which is not ideal.
> > > > >
> > > > > Are there any custom executors out there that crash if they get
> Tasks
> > > > with
> > > > > CommandInfo set?
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Vinod
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards,
> > > > Haosdent Huang
> > > >
> > > > --
> > > > Zameer Manji
> > > >
> > >
> >
> > --
> > Zameer Manji
> >
>

--001a114286e4f2929c05405880fc--