-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/42126/#review114372
-----------------------------------------------------------
Master (952ef6d) is red with this patch.
./build-support/jenkins/build.sh
[1m
self._clock.converge(threads=[hct.threaded_health_checker])[0m
[1m
self._clock.assert_waiting(hct.threaded_health_checker, amount=1)[0m
[1m [0m
[1m assert hct._total_latency == 0[0m
[1m assert
hct.metrics.sample()['total_latency_secs'] == 0[0m
[1m [0m
[1m # start the health check (during health check it
is still 0)[0m
[1m epsilon = 0.001[0m
[1m self._clock.tick(1.0 + epsilon)[0m
[1m
self._clock.converge(threads=[hct.threaded_health_checker])[0m
[1m
self._clock.assert_waiting(hct.threaded_health_checker, amount=0.5)[0m
[1m assert hct._total_latency == 0[0m
[1m assert
hct.metrics.sample()['total_latency_secs'] == 0[0m
[1m assert hct.metrics.sample()['checks'] == 0[0m
[1m [0m
[1m # finish the health check[0m
[1m self._clock.tick(0.5 + epsilon)[0m
[1m
self._clock.converge(threads=[hct.threaded_health_checker])[0m
[1m
self._clock.assert_waiting(hct.threaded_health_checker, amount=1) #
interval_secs[0m
[1m> assert hct._total_latency == 0.5[0m
[1m[31mE AssertionError: assert 0.5009999999999999
== 0.5[0m
[1m[31mE + where 0.5009999999999999 =
<apache.aurora.executor.common.health_checker.HealthChecker object at
0x7fc2a9a57210>._total_latency[0m
src/test/python/apache/aurora/executor/common/test_health_checker.py:174:
AssertionError
-------------- Captured stderr call --------------
[<twitter.common.testing.clock.ThreadedClock object at
0x7fc2a9a57550>] Time now: 0.0
[<twitter.common.testing.clock.ThreadedClock object at
0x7fc2a9a57550>] Time now: 0.0
[<twitter.common.testing.clock.ThreadedClock object at
0x7fc2a9a57550>] Time now: 1.0
[<twitter.common.testing.clock.ThreadedClock object at
0x7fc2a9a57550>] Time now: 1.001
[<twitter.common.testing.clock.ThreadedClock object at
0x7fc2a9a57550>] Time now: 1.001
[<twitter.common.testing.clock.ThreadedClock object at
0x7fc2a9a57550>] Time now: 1.501
[<twitter.common.testing.clock.ThreadedClock object at
0x7fc2a9a57550>] Time now: 1.502
generated xml file:
/home/jenkins/jenkins-slave/workspace/AuroraBot/dist/test-results/src.test.python.apache.aurora.executor.common.common.xml
[1m[31m= 1 failed, 42 passed, 2 skipped in 3.47 seconds
=[0m
FAILURE
01:51:26 05:22 [complete][31m
FAILURE[0m
I will refresh this build result if you post a review containing "@ReviewBot
retry"
- Aurora ReviewBot
On Jan. 14, 2016, 1:39 a.m., Zhitao Li wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42126/
> -----------------------------------------------------------
>
> (Updated Jan. 14, 2016, 1:39 a.m.)
>
>
> Review request for Aurora, Maxim Khutornenko, Dmitriy Shirchenko, and Bill
> Farner.
>
>
> Bugs: AURORA-1109
> https://issues.apache.org/jira/browse/AURORA-1109
>
>
> Repository: aurora
>
>
> Description
> -------
>
> This review is a prototype for introducing multiple role support in Aurora.
> This creates a new class OfferAllocation, which allcoates resources to
> resources field in TaskInfo and ExecutorInfo from an offer.
>
> Current implementation prefers reserved resources over shared resources ('*'
> role) if both are present
>
> Several caveats:
> 1. This performs the allocate after scheduling decision in
> TaskAssigner.maybeAssign is done, which leaves possibility of inconsistency
> and late failure.
>
>
> Diffs
> -----
>
> NEWS acaff9eb2ab184b0ef750f8b8a00c20131997f6b
> src/main/java/org/apache/aurora/scheduler/AcceptedOffer.java PRE-CREATION
> src/main/java/org/apache/aurora/scheduler/ResourceSlot.java
> 7c3d681c216b78eeecebbe950186e5a79c6fe982
> src/main/java/org/apache/aurora/scheduler/Resources.java
> db422a959ee7b982c2a44323de41ad75d1a40754
>
> src/main/java/org/apache/aurora/scheduler/mesos/CommandLineDriverSettingsModule.java
> 2255dd407cd1810c7df5baf17cfa85f79bfffeb8
> src/main/java/org/apache/aurora/scheduler/mesos/MesosTaskFactory.java
> 8fdadda67478bb3110aa442b7d78493cf9c3edb4
> src/main/java/org/apache/aurora/scheduler/state/TaskAssigner.java
> 7e8e456e288986eb0ce92a123b294e1e25d8ed18
> src/test/java/org/apache/aurora/scheduler/AcceptedOfferTest.java
> PRE-CREATION
> src/test/java/org/apache/aurora/scheduler/ResourceSlotTest.java
> e4ae943303823ac4bfbe999ed22f5999484462d8
>
> src/test/java/org/apache/aurora/scheduler/mesos/CommandLineDriverSettingsModuleTest.java
> 33149ab415292eff04f38b61f2b1d1eac79f347a
>
> src/test/java/org/apache/aurora/scheduler/mesos/MesosTaskFactoryImplTest.java
> a5793bffabf4e5d6195b1b99f2363d241c0cecf9
> src/test/java/org/apache/aurora/scheduler/state/TaskAssignerImplTest.java
> 3cbe9acd75def14ae2e0986914ba621fb164b3e4
>
> Diff: https://reviews.apache.org/r/42126/diff/
>
>
> Testing
> -------
>
> 1. Unit tested with old and new tests;
> 2. vagrant integration tests: I manually separate out the vagrant box's cpu
> and memory between 'aurora-test' role and '*' and verified that jobs can
> still be launched (I can post the vagrant change in another follow upon
> request).
>
>
> Thanks,
>
> Zhitao Li
>
>
