> On March 31, 2016, 4:20 p.m., Dmitriy Shirchenko wrote:
> > src/main/python/apache/aurora/common/health_check/shell.py, line 66
> > <https://reviews.apache.org/r/45506/diff/2/?file=1320188#file1320188line66>
> >
> >     why are you doing a separate try/except with timeout when 
> > subprocess.Popen already supports it.
> >     
> >     you can still do a kill if that's your intention in one swoop.
> 
> Bill Farner wrote:
>     I'm generally a fan of scoping exceptions to catch only where they are 
> known to be thrown.  If `Popen.__init__` and `Popen.wait` threw the same 
> exception type, i would probably put them in the same `try`, but in this case 
> they are distinct.
>     
>     However, i'm not sure what you mean by 'Popen already supports it', so 
> it's possible i'm missing something.
> 
> Dmitriy Shirchenko wrote:
>     If you look at subprocess32, timeout is an option into Popen. What's the 
> logic behind changing how timeout is done via process.wait instead of relying 
> on Popen()?
> 
> Bill Farner wrote:
>     I don't see a `timeout` kwarg on any `Popen` docs or sources.
>     
>     https://docs.python.org/3.3/library/subprocess.html#popen-constructor
>     
> https://github.com/google/python-subprocess32/blob/master/subprocess32.py#L716-L722

`check_call` has it. I was wrong: made a wrong assumption that Popen has it. 
https://github.com/google/python-subprocess32/blob/master/subprocess32.py#L587

I guess question should be rephrased: why switch to Popen when `check_call` 
does what we need and it just a wrapper around Popen with timeout.


- Dmitriy


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


On March 31, 2016, 6:57 p.m., Bill Farner wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45506/
> -----------------------------------------------------------
> 
> (Updated March 31, 2016, 6:57 p.m.)
> 
> 
> Review request for Aurora, Dmitriy Shirchenko and Zameer Manji.
> 
> 
> Bugs: AURORA-1641
>     https://issues.apache.org/jira/browse/AURORA-1641
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> Here's a stab at this using `os` and `pwd` modules directly to demote health 
> checks to the target user.
> 
> 
> Diffs
> -----
> 
>   src/main/python/apache/aurora/common/health_check/shell.py 
> 6cb7dfc164f4e16143fc974d50c19a5887d32015 
>   src/main/python/apache/aurora/executor/common/health_checker.py 
> 28fd3ec3ef7d0b66621c0295804af0eb72c64b4a 
>   src/test/python/apache/aurora/common/health_check/test_shell.py 
> 7026af8c4671a40f4b517ecf12149eac34a552c8 
>   src/test/python/apache/aurora/executor/common/test_health_checker.py 
> 19c4f76347e34374c29974c182d1f4c118bcb18d 
>   src/test/sh/org/apache/aurora/e2e/http/http_example_bad_healthcheck.aurora 
> c709b035a54822ff700136963e2f942f30f38898 
>   src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh 
> e1c12bbd4382c31e576439f6693d82d5661029b9 
> 
> Diff: https://reviews.apache.org/r/45506/diff/
> 
> 
> Testing
> -------
> 
> Altered an end-to-end test case to verify that shell checks are not run as a 
> privileged user.
> 
> 
> Thanks,
> 
> Bill Farner
> 
>

Reply via email to