You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by Gidon Gershinsky <gg...@gmail.com> on 2015/07/02 16:18:03 UTC

Task revocation

Hi,

We are developing a resource allocation module, using the new plug-in
mechanism (taken directly from Github, thanks Alex, works smooth).

Our module will need to revoke/kill tasks, eg to make space for more
important ones (say when they call driver.requestResources, and no
resources are available). I know task revocation can't be done currently
from the master/module, but there is a driver API that enables frameworks
to kill their tasks.

I can implement an out-of-band mechanism, where the module will communicate
with frameworks on a proprietary protocol, and tell them to kill a task.
But I wonder if there is another option for master-framework messaging
(callable from the allocation module), maybe similar to executor-framework
messaging? Or plans to add kill task API in the master/module?

Thanks, Gidon

Re: Task revocation

Posted by Adam Bordelon <ad...@mesosphere.io>.
Gidon,

If your allocation module is capable of sending protobuf messages to the
master, you could send a KillTaskMessage with the proper frameworkId and
taskId and hack a way around the if condition at
https://github.com/apache/mesos/blob/0.23.0-rc1/src/master/master.cpp#L2946
I think in general, it would be great to add an authenticated/authorized
killTask endpoint on the master, for operators, tools, or services like
your allocator to use to kill tasks. This may be incorporated in the
upcoming HTTP API redesign.

On Thu, Jul 2, 2015 at 8:42 AM, Gidon Gershinsky <gg...@gmail.com> wrote:

> Thanks.
>
> Yep, that's what I meant by an out-of-band option. I wonder if there is a
> direct way to kill a task from inside a resource allocation module. Or to
> send a message from the resource allocation module to a framework.
>
> On Thu, Jul 2, 2015 at 6:09 PM, haosdent <ha...@gmail.com> wrote:
>
> > Hi, @Gidon. In fact, when you call framework.killTask. The framework
> would
> > send a KillTaskMessage contains frameworkId and taskId to Master. And
> then
> > Master forward this message to Slave. Ask Slave to kill this task.
> >
> > On Thu, Jul 2, 2015 at 10:18 PM, Gidon Gershinsky <gg...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > We are developing a resource allocation module, using the new plug-in
> > > mechanism (taken directly from Github, thanks Alex, works smooth).
> > >
> > > Our module will need to revoke/kill tasks, eg to make space for more
> > > important ones (say when they call driver.requestResources, and no
> > > resources are available). I know task revocation can't be done
> currently
> > > from the master/module, but there is a driver API that enables
> frameworks
> > > to kill their tasks.
> > >
> > > I can implement an out-of-band mechanism, where the module will
> > communicate
> > > with frameworks on a proprietary protocol, and tell them to kill a
> task.
> > > But I wonder if there is another option for master-framework messaging
> > > (callable from the allocation module), maybe similar to
> > executor-framework
> > > messaging? Or plans to add kill task API in the master/module?
> > >
> > > Thanks, Gidon
> > >
> >
> >
> >
> > --
> > Best Regards,
> > Haosdent Huang
> >
>

Re: Task revocation

Posted by Gidon Gershinsky <gg...@gmail.com>.
Thanks.

Yep, that's what I meant by an out-of-band option. I wonder if there is a
direct way to kill a task from inside a resource allocation module. Or to
send a message from the resource allocation module to a framework.

On Thu, Jul 2, 2015 at 6:09 PM, haosdent <ha...@gmail.com> wrote:

> Hi, @Gidon. In fact, when you call framework.killTask. The framework would
> send a KillTaskMessage contains frameworkId and taskId to Master. And then
> Master forward this message to Slave. Ask Slave to kill this task.
>
> On Thu, Jul 2, 2015 at 10:18 PM, Gidon Gershinsky <gg...@gmail.com>
> wrote:
>
> > Hi,
> >
> > We are developing a resource allocation module, using the new plug-in
> > mechanism (taken directly from Github, thanks Alex, works smooth).
> >
> > Our module will need to revoke/kill tasks, eg to make space for more
> > important ones (say when they call driver.requestResources, and no
> > resources are available). I know task revocation can't be done currently
> > from the master/module, but there is a driver API that enables frameworks
> > to kill their tasks.
> >
> > I can implement an out-of-band mechanism, where the module will
> communicate
> > with frameworks on a proprietary protocol, and tell them to kill a task.
> > But I wonder if there is another option for master-framework messaging
> > (callable from the allocation module), maybe similar to
> executor-framework
> > messaging? Or plans to add kill task API in the master/module?
> >
> > Thanks, Gidon
> >
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: Task revocation

Posted by haosdent <ha...@gmail.com>.
Hi, @Gidon. In fact, when you call framework.killTask. The framework would
send a KillTaskMessage contains frameworkId and taskId to Master. And then
Master forward this message to Slave. Ask Slave to kill this task.

On Thu, Jul 2, 2015 at 10:18 PM, Gidon Gershinsky <gg...@gmail.com> wrote:

> Hi,
>
> We are developing a resource allocation module, using the new plug-in
> mechanism (taken directly from Github, thanks Alex, works smooth).
>
> Our module will need to revoke/kill tasks, eg to make space for more
> important ones (say when they call driver.requestResources, and no
> resources are available). I know task revocation can't be done currently
> from the master/module, but there is a driver API that enables frameworks
> to kill their tasks.
>
> I can implement an out-of-band mechanism, where the module will communicate
> with frameworks on a proprietary protocol, and tell them to kill a task.
> But I wonder if there is another option for master-framework messaging
> (callable from the allocation module), maybe similar to executor-framework
> messaging? Or plans to add kill task API in the master/module?
>
> Thanks, Gidon
>



-- 
Best Regards,
Haosdent Huang