Mailing-List: contact issues-help@mesos.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mesos.apache.org
Date: Tue, 15 Nov 2016 07:53:58 +0000 (UTC)
From: "Markus Jura (JIRA)" <jira@apache.org>
To: issues@mesos.apache.org
Message-ID: <JIRA.13020489.1479124608000.278098.1479196438360@Atlassian.JIRA>
In-Reply-To: <JIRA.13020489.1479124608000@Atlassian.JIRA>
References: <JIRA.13020489.1479124608000@Atlassian.JIRA> <JIRA.13020489.1479124608957@arcas>
Subject: [jira] [Updated] (MESOS-6586) Teardown endpoint should remove
 framework
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 15 Nov 2016 07:54:00 -0000


     [ https://issues.apache.org/jira/browse/MESOS-6586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Markus Jura updated MESOS-6586:
-------------------------------
    Description: 
The Mesos {{/teardown}} endpoint is:
- Removing the framework on the mesos-master. As a result, the framework is in state {{removed}}
- Shuts down all executors and tasks running on the Mesos agents

However, I'd also expect that a message from the mesos-master is sent to the framework (Scheduler API) so that the framework processes can initiate a shutdown as well. This is not the case. As a result, it is necessary to manually {{suspend}} the framework, e.g. by using the DC/OS UI.

A possible solution would be to provide an additional callback {{teardown}} at the scheduler API that will notify the framework that the mesos-master has initiated a teardown. Mesos-master should only mark the framework as removed if the framework has been successfully terminated, e.g. the framework could send a message to mesos-master indicating that the termination was successful / has been started.

This change will also affect the {{dcos service shutdown}} command which uses the {{/teardown}} endpoint. From a DC/OS CLI perspective, I'd expect that the {{dcos service shutdown service-id}} command shuts down all components of the framework, not only the executors and tasks.

Also, for consistency reasons I'd expect that this shutdown action can also be taken by using the DC/OS UI. So far on DC/OS, you can only {{Suspend}} a service / framework which will stop the framework instances, but will not remove the framework from mesos-master and terminate it's executors. As far as I am aware there is no documentation that explains in detail the difference between the {{shutdown}} command in the DC/OS CLI and the {{Suspend}} button on the DC/OS UI. A user should carefully understand what these actions are doing with the system, especially if they are not consistent. Again, I'd recommend adding a new button to the DC/OS UI that uses the {{/teardown}} endpoint.

Tested on DC/OS with the frameworks conductr and elasticsearch.

  was:
The Mesos {{/teardown}} endpoint is:
- Removing the framework on the mesos-master. As a result, the framework is in state {{removed}}
- Shuts down all executors and tasks running on the Mesos agents

However, I'd also expect that a message from the mesos-master is sent to the framework (Scheduler API) so that the framework processes can initiate a shutdown as well. This is not the case. As a result, it is necessary to manually {{suspend}} the framework, e.g. by using the DC/OS UI.

A possible solution would be to provide an additional callback {{teardown}} at the scheduler API that will notify the framework that the mesos-master has initiated a teardown. Mesos-master should only mark the framework as removed if the framework has been successfully terminated, e.g. the framework could send a message to mesos-master indicating that the termination was successful / has been started.

This change will also affect the {{dcos service shutdown}} command which uses the {{/teardown}} endpoint. From a DC/OS CLI perspective, I'd expect that the {{dcos service shutdown service-id}} command shuts down all components of the framework, not only the executors and tasks.

Also, for consistency reasons I'd expect that this shutdown action can also be taken by using the DC/OS UI. So far on DC/OS, you can only {{Suspend}} a service / framework which will stop the framework instances, but will not remove the framework from mesos-master and terminate it's executors. As far as I am aware there is no documentation that explains in detail the difference between the {{shutdown}} command in the DC/OS CLI and the {{Suspend}} button on the DC/OS UI. A user should carefully understand what these actions are doing with the system, especially if they are not consistent. Again, I'd recommend to add a new button to the DC/OS UI that uses the {{/teardown}} endpoint.

Tested on DC/OS with the frameworks conductr and elasticsearch.


> Teardown endpoint should remove framework
> -----------------------------------------
>
>                 Key: MESOS-6586
>                 URL: https://issues.apache.org/jira/browse/MESOS-6586
>             Project: Mesos
>          Issue Type: Improvement
>          Components: cli, framework api, HTTP API
>    Affects Versions: 1.0.1
>            Reporter: Markus Jura
>              Labels: features
>
> The Mesos {{/teardown}} endpoint is:
> - Removing the framework on the mesos-master. As a result, the framework is in state {{removed}}
> - Shuts down all executors and tasks running on the Mesos agents
> However, I'd also expect that a message from the mesos-master is sent to the framework (Scheduler API) so that the framework processes can initiate a shutdown as well. This is not the case. As a result, it is necessary to manually {{suspend}} the framework, e.g. by using the DC/OS UI.
> A possible solution would be to provide an additional callback {{teardown}} at the scheduler API that will notify the framework that the mesos-master has initiated a teardown. Mesos-master should only mark the framework as removed if the framework has been successfully terminated, e.g. the framework could send a message to mesos-master indicating that the termination was successful / has been started.
> This change will also affect the {{dcos service shutdown}} command which uses the {{/teardown}} endpoint. From a DC/OS CLI perspective, I'd expect that the {{dcos service shutdown service-id}} command shuts down all components of the framework, not only the executors and tasks.
> Also, for consistency reasons I'd expect that this shutdown action can also be taken by using the DC/OS UI. So far on DC/OS, you can only {{Suspend}} a service / framework which will stop the framework instances, but will not remove the framework from mesos-master and terminate it's executors. As far as I am aware there is no documentation that explains in detail the difference between the {{shutdown}} command in the DC/OS CLI and the {{Suspend}} button on the DC/OS UI. A user should carefully understand what these actions are doing with the system, especially if they are not consistent. Again, I'd recommend adding a new button to the DC/OS UI that uses the {{/teardown}} endpoint.
> Tested on DC/OS with the frameworks conductr and elasticsearch.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)