[
https://issues.apache.org/jira/browse/MESOS-3220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14728029#comment-14728029
]
Vinod Kone commented on MESOS-3220:
-----------------------------------
Framework knowing about it *after* the task gets killed is likely not enough.
Frameworks typically plan redundancy of tasks (e.g., replicas) based on
"unplanned" random failures in a DC. Adding these sort of endpoints violates
such assumptions.
For example, for planned machine maintenance we explicitly took the design
decision for Mesos to not kill tasks but to have it send inverse offers to give
the opportunity for frameworks to react (say yes or no).
Should we do something similar for this endpoint?
Also, I don't follow the "disparate ways to talk to every framework" point.
Does DCOS CLI allow launching framework's tasks? If yes, it already knows how
to communicate with frameworks. If not, why should it allow killing them?
Moreover, I am surprised that there are Mesos frameworks out there that have
APIs for launching tasks but not killing them!?
I'm asking these hard questions, because a similar question came up with Aurora
devs (cc [~maximk]) with regards to a Mesos endpoint for killing all revocable
tasks in case of emergency. I'm still debating what's the right way to go about
such requests.
> Offer ability to kill tasks from the API
> ----------------------------------------
>
> Key: MESOS-3220
> URL: https://issues.apache.org/jira/browse/MESOS-3220
> Project: Mesos
> Issue Type: Improvement
> Components: python api
> Reporter: Sunil Shah
> Assignee: Marco Massenzio
> Priority: Blocker
> Labels: mesosphere
>
> We are investigating adding a `dcos task kill` command to our DCOS (and
> Mesos) command line interface. Currently the ability to kill tasks is only
> offered via the scheduler API so it would be useful to have some ability to
> kill tasks directly.
> This is a blocker for the DCOS CLI!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
