It isn't issue if it a broadening of possibilities.
I would like to point out that, if we do want to have a better contract in
the future (ie a set of CommandInfos), we are setting up ourselves for a
API change in the future.
If we clearly document that the CommandInfo is just passed down to the
@zameer
I think your example makes a lot of sense. I didn't interpret the proposal
as one that would prevent your case.
The way I read the proposal is that we want to allow setting both, not
require it. If I misunderstood then please ignore my comments.
When I first heard about this proposal it
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 wrote:
> Joris,
>
> You make a good point. However, I'm not convinced
Joris,
You make a good point. However, I'm not convinced that `CommandInfo` should
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
Comma
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 building
out a few different flavors of executor
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 t
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
