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



This patch does not apply cleanly against master (e76862a), do you need to 
rebase?

I will refresh this build result if you post a review containing "@ReviewBot 
retry"

- Aurora ReviewBot


On May 31, 2017, 11:44 p.m., Jordan Ly wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59640/
> -----------------------------------------------------------
> 
> (Updated May 31, 2017, 11:44 p.m.)
> 
> 
> Review request for Aurora, David McLaughlin, Santhosh Kumar Shanmugham, 
> Stephan Erb, and Zameer Manji.
> 
> 
> Bugs: AURORA-1928
>     https://issues.apache.org/jira/browse/AURORA-1928
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> Currently, when updating a job we choose to update instances naively by 
> ascending instance ID number.
> However, it would be better to add new instances before killing and updating 
> older instances.
> 
> This patch makes it so the job updater prefers to create new instances, then
> update instances, and finally kill instances.
> 
> 
> Diffs
> -----
> 
>   RELEASE-NOTES.md 75b3ddb856dc5d889a9006490f57cc58ee7d82fc 
>   docs/features/job-updates.md 60968aeb47e787720e3a29b33e31f66d3f0c9839 
>   src/main/java/org/apache/aurora/scheduler/updater/UpdateFactory.java 
> 14c2d2de3186271819a5f4e527d3b30fd34d2b21 
>   src/test/java/org/apache/aurora/scheduler/updater/JobUpdaterIT.java 
> 290385d737294e23e9dd50f2631303124aa7af7c 
>   
> src/test/java/org/apache/aurora/scheduler/updater/UpdateFactoryImplTest.java 
> 611f6b8681c8e0b286cd361bdb5ace1fea39d9a5 
> 
> 
> Diff: https://reviews.apache.org/r/59640/diff/2/
> 
> 
> Testing
> -------
> 
> Ran unit tests and integration tests.
> 
> Had to modify some integration tests since we now prefer to create over 
> update -- needed to change
> the ordering of actions. Additionally, some unit tests only specified configs 
> for one instance even
> though desiredInstances is always 2 -- had to make it so the range of 
> configurations is always 0-2
> when creating. Otherwise, it would try to create instances first even though 
> the test didn't really
> care.
> 
> Tested different update configurations on the Vagrant cluster: only adding 
> instances, only updating
> instances, only killing instances, create & update, update & kill.
> 
> 
> Thanks,
> 
> Jordan Ly
> 
>

Reply via email to