Mailing-List: contact reviews-help@aurora.apache.org; run by ezmlm
Precedence: bulk
Reply-To: reviews@aurora.apache.org
Content-Type: multipart/alternative;
 boundary="===============4541881782528040717=="
MIME-Version: 1.0
Subject: Re: Review Request 59733: Adding Configurable Wait Period for Graceful
 Shutdowns
From: Zameer Manji <zmanji@apache.org>
To: Santhosh Kumar Shanmugham <santhoshkumar.s@gmail.com>,
 David McLaughlin <david@dmclaughlin.com>, Stephan Erb <serb@apache.org>,
 Zameer Manji <zmanji@apache.org>
Cc: Aurora <reviews@aurora.apache.org>, Jordan Ly <jordan.ly8@gmail.com>
Date: Fri, 02 Jun 2017 17:28:01 -0000
Message-ID: <20170602172801.16397.73042@reviews-vm2.apache.org>
Auto-Submitted: auto-generated
Sender: Zameer Manji <noreply@reviews.apache.org>
References: <20170601234802.34605.69330@reviews-vm2.apache.org>
In-Reply-To: <20170601234802.34605.69330@reviews-vm2.apache.org>
Reply-To: Zameer Manji <zmanji@apache.org>
archived-at: Fri, 02 Jun 2017 17:28:05 -0000

--===============4541881782528040717==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59733/#review176802
-----------------------------------------------------------


I don't have comment access on the doc, so I will leave my questions here:

1. Should operators (via executor flags) be able to cap this value? That is should `STOP_TIMEOUT` be an operator flag?
2. Should the client cap this value and display an error message to the user?
3. AFAIK, a task can remain in `KILLING` forever. There is no timeout in the scheduler, as it just retries kills. If a user puts a large value here, I'm not sure tasks will actually termiante. Please add an e2e test here to confirm/deny.

- Zameer Manji


On June 1, 2017, 4:48 p.m., Jordan Ly wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59733/
> -----------------------------------------------------------
> 
> (Updated June 1, 2017, 4:48 p.m.)
> 
> 
> Review request for Aurora, David McLaughlin, Santhosh Kumar Shanmugham, Stephan Erb, and Zameer Manji.
> 
> 
> Bugs: AURORA-1931
>     https://issues.apache.org/jira/browse/AURORA-1931
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> We have some services that require more than the current 10 seconds given to 
> gracefully shutdown (they need to close resources, finish requests, etc).
> 
> We would like to be able to configure the amount of time we wait between each
> stage of the graceful shutdown sequence. See this [proposal](https://docs.google.com/document/d/1Sl-KWNyt1j0nIndinqfJsH3pkUY5IYXfGWyLHU2wacs/edit?usp=sharing) for a more in-depth
> analysis.
> 
> 
> Diffs
> -----
> 
>   src/main/python/apache/aurora/config/schema/base.py b2692a648645a195a24491e4978fb833c6c20be8 
>   src/main/python/apache/aurora/executor/aurora_executor.py 81461cb49ac223f3bdfa59e8c59e150a07771dea 
>   src/main/python/apache/aurora/executor/http_lifecycle.py 9280bf29da9bda1691adbf3a4c34c4f3d4900517 
>   src/test/python/apache/aurora/client/cli/test_inspect.py 4a23c5984c2d093e2f53e93aec71418f84b65928 
>   src/test/python/apache/aurora/executor/test_http_lifecycle.py a967e3410a4d2dc2e1721f505a4d76da9209d177 
>   src/test/python/apache/aurora/executor/test_thermos_task_runner.py 1b92667bceabc8ea1540122477a51cb58ea2ae36 
> 
> 
> Diff: https://reviews.apache.org/r/59733/diff/1/
> 
> 
> Testing
> -------
> 
> Ran unit and integration tests.
> 
> Created and killed jobs with varying wait_escalation_secs values on the Vagrant devcluster.
> 
> 
> Thanks,
> 
> Jordan Ly
> 
>


--===============4541881782528040717==--