This is an automatically generated e-mail. To reply, visit:

docs/configuration-reference.md (lines 387 - 389)

    Does anyone think it would be worth a deprecation cycle to rename these 
http-specific parameters to have an http prefix? It seems like it would be a 
major hassle, but also potentially seems like the right thing to do?
    We could, potentially add something to rewrite tasks using the current 
values to the new values as well?

docs/configuration-reference.md (line 390)


docs/configuration-reference.md (line 392)

    s/that tolerated/that will be tolerated

docs/configuration-reference.md (line 393)

    "An alternative to HTTP health checking. Specifies a shell command that 
will be executed. Any non-zero exit status will be interpreted as a health 
check failure."

src/main/python/apache/aurora/client/config.py (lines 98 - 110)

    I feel like this validation, while absolutely important on the client, 
should also be verified elsewhere... I don't think the Scheduler does anything 
other than pass this through to the executor, so probably the executor should 
validate it when starting the task? My concern is someone who does not use the 
client, but uses the API directly to create tasks would be able to send invalid 
config and either have undefined health check behavior, no health check, or 
just have a mysterious task failure.
    If we performed explicit validation in the executor when creating the 
health checker we at least could exit with an explicit reason that makes it 
clear that the health check config was invalid.

src/main/python/apache/aurora/executor/common/health_checker.py (line 247)

    This behavior is slightly changed from the current behavior, where if the 
user did not opt in to health checks (by not binding a `health` port), we would 
return `None`.
    Now if they did not bind a `health` port, but type is `shell` with no 
command we'll return an invalidly configured HealthChecker (It will have a 
ShellHealthCheck with no cmd set which will eventually cause the executor to 
fail when health check is run). This ties in to the need to validate in the 
executor that I mentioned above.
    Beyond that though, I've found there's been value in being able to 
configure a health check, but then, e.g. not have the devel version of your 
task bind a `health` port, opting out of health checking for those tasks. I'm 
not sure if there's a great way to replicate that behavior for shell health 
checks (e.g. add an `enabled` field to `HealthCheckConfig`, seems a bit gross) 
and if it's a useful enough "feature" to warrant replicating, but I figured I'd 
bring it up for discussion regardless.

src/test/python/apache/aurora/common/BUILD (line 25)

    I don't think we need this dependency here. The tests under health_check 
will be picked up when we run a recrusive target regardless.

src/test/python/apache/aurora/common/health_check/test_shell.py (line 39)

    Mind splitting these up into individual test cases?

- Joshua Cohen

On Dec. 11, 2015, 12:08 a.m., Dmitriy Shirchenko wrote:
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41154/
> -----------------------------------------------------------
> (Updated Dec. 11, 2015, 12:08 a.m.)
> Review request for Aurora, Maxim Khutornenko, Bill Farner, and Zameer Manji.
> Bugs: AURORA-1551
>     https://issues.apache.org/jira/browse/AURORA-1551
> Repository: aurora
> Description
> -------
> Adding support for non-HTTP health checks.
> Diffs
> -----
>   3rdparty/python/requirements.txt cfef18ee66b0f92d83c53dacb6d9376fc2e50445 
>   docs/configuration-reference.md 364292998bebb233d300fe59c9ea42b216deee81 
>   src/main/python/apache/aurora/client/config.py 
> 2fc12559016d406c347adb416a5166cca31c961e 
>   src/main/python/apache/aurora/common/BUILD 
> 5fce3d0d29d2a38c6563b4d9be963532e595ee19 
>   src/main/python/apache/aurora/common/health_check/__init__.py PRE-CREATION 
>   src/main/python/apache/aurora/common/health_check/shell.py PRE-CREATION 
>   src/main/python/apache/aurora/common/http_signaler.py 
> a3193f3259276ec23d37f45839afe3c387cff6b1 
>   src/main/python/apache/aurora/config/schema/base.py 
> 398f737bed9ef02ce4a5636896d6587bce26501e 
>   src/main/python/apache/aurora/executor/common/health_checker.py 
> 03fdf0afef120c365c6ffad09e152780eed7e351 
>   src/main/python/apache/aurora/executor/http_lifecycle.py 
> 6d578cceb56375425ccac1cbfbbcd0add60f20e9 
>   src/test/python/apache/aurora/client/BUILD 
> 84c5c845d9b1c8078ae8b47242d0f2ffc00ef6dc 
>   src/test/python/apache/aurora/client/test_config.py 
> b1a3c1865819899ef19173be0f861783a2631d0a 
>   src/test/python/apache/aurora/common/BUILD 
> 2556c32842b3cf7040cb3c41172a0d9c365cb649 
>   src/test/python/apache/aurora/common/health_check/BUILD PRE-CREATION 
>   src/test/python/apache/aurora/common/health_check/__init__.py PRE-CREATION 
>   src/test/python/apache/aurora/common/health_check/test_shell.py 
>   src/test/python/apache/aurora/common/test_http_signaler.py 
> f68c71a6765f7f0b93c8c50662515b5742344f35 
>   src/test/python/apache/aurora/executor/common/test_health_checker.py 
> 27c71711d52f757ed1552db4accda671a6bdafdd 
> Diff: https://reviews.apache.org/r/41154/diff/
> Testing
> -------
> Added unit tests. 
> Ran e2e test.
> Tested expected behavior on virtual Mesos cluster.
> Thanks,
> Dmitriy Shirchenko

Reply via email to