date:20171108

Re: Review Request 63685: RFC: Use new scheduler UI as landing page

2017-11-08 Thread Bill Farner


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



I agree with the direction, and i agree that we should try for a redirect-free 
experience.  Thought added below.


src/main/java/org/apache/aurora/scheduler/http/JettyServerModule.java
Line 334 (original), 334 (patched)


I may be misunderstanding the goal, but i would have expected this line to 
change to:
```
.put("/(?:index.html)?", "/assets/scheduler/index.html")
```

This should serve the scheduler UI when accessing `/` or `/index.html`.


- Bill Farner


On Nov. 8, 2017, 2:32 p.m., Stephan Erb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/63685/
> ---
> 
> (Updated Nov. 8, 2017, 2:32 p.m.)
> 
> 
> Review request for Aurora, David McLaughlin and Joshua Cohen.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> Is this something the community would be interested in?
> 
> Known issues in this minimal viable prototype:
> 
> * I did not manage to convince Jetty to perform the redirecting. Using the 
> HTML feels hacky but works.
> * An operator will have difficulties to navigate to /admin of a non-leading 
> instance. In particular if there is no leader at all.
> 
> 
> Diffs
> -
> 
>   src/main/java/org/apache/aurora/scheduler/http/JettyServerModule.java 
> 0f8528c3403b5f51f082aa54c16358f7568f439a 
>   src/main/resources/scheduler/assets/index.html 
> 533091395547a6b067dbf5f53e42a13a560971da 
>   ui/src/main/js/components/Navigation.js 
> 50881a9914cee2812807624cd28f24fa64207296 
>   ui/src/main/js/index.js 9f94d4bd6f649d74bdd9c3aa99783e01cae25d93 
>   ui/src/main/js/pages/Admin.js PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/63685/diff/1/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Screen Shot 2017-11-08 at 23.18.06.png
>   
> https://reviews.apache.org/media/uploaded/files/2017/11/08/80ae2c5f-e431-4f86-8811-13bfe6a8627b__Screen_Shot_2017-11-08_at_23.18.06.png
> Screen Shot 2017-11-08 at 23.18.20.png
>   
> https://reviews.apache.org/media/uploaded/files/2017/11/08/9fb0f2e0-49c9-427f-8b84-d3d1fc057a59__Screen_Shot_2017-11-08_at_23.18.20.png
> 
> 
> Thanks,
> 
> Stephan Erb
> 
>

Re: Review Request 63685: RFC: Use new scheduler UI as landing page

2017-11-08 Thread Joshua Cohen


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



In general I think the spirit of this change makes sense, but as you mention, 
the HTTP redirect is definitely not ideal. It should certainly be possible to 
serve up the actual scheduler UI by default without the need to redirect. Off 
the top of my head I'm not sure exactly what would need to be done though.

- Joshua Cohen


On Nov. 8, 2017, 10:32 p.m., Stephan Erb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/63685/
> ---
> 
> (Updated Nov. 8, 2017, 10:32 p.m.)
> 
> 
> Review request for Aurora, David McLaughlin and Joshua Cohen.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> Is this something the community would be interested in?
> 
> Known issues in this minimal viable prototype:
> 
> * I did not manage to convince Jetty to perform the redirecting. Using the 
> HTML feels hacky but works.
> * An operator will have difficulties to navigate to /admin of a non-leading 
> instance. In particular if there is no leader at all.
> 
> 
> Diffs
> -
> 
>   src/main/java/org/apache/aurora/scheduler/http/JettyServerModule.java 
> 0f8528c3403b5f51f082aa54c16358f7568f439a 
>   src/main/resources/scheduler/assets/index.html 
> 533091395547a6b067dbf5f53e42a13a560971da 
>   ui/src/main/js/components/Navigation.js 
> 50881a9914cee2812807624cd28f24fa64207296 
>   ui/src/main/js/index.js 9f94d4bd6f649d74bdd9c3aa99783e01cae25d93 
>   ui/src/main/js/pages/Admin.js PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/63685/diff/1/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Screen Shot 2017-11-08 at 23.18.06.png
>   
> https://reviews.apache.org/media/uploaded/files/2017/11/08/80ae2c5f-e431-4f86-8811-13bfe6a8627b__Screen_Shot_2017-11-08_at_23.18.06.png
> Screen Shot 2017-11-08 at 23.18.20.png
>   
> https://reviews.apache.org/media/uploaded/files/2017/11/08/9fb0f2e0-49c9-427f-8b84-d3d1fc057a59__Screen_Shot_2017-11-08_at_23.18.20.png
> 
> 
> Thanks,
> 
> Stephan Erb
> 
>

Re: Review Request 63536: Give jobs the ability to determine how to handle partitions by integrating with new Mesos Partition-Aware APIs

2017-11-08 Thread Jordan Ly


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



Overall the logic seems sound to me!


src/main/java/org/apache/aurora/scheduler/state/PartitionManager.java
Lines 57 (patched)


I don't think you need to `synchronize` here since it is a 
`ConcurrentHashMap`. You can probably just call `remove`, and if the value it 
returns is not `null` you can cancel it.

This way, you can remove the double-checked locking.



src/main/java/org/apache/aurora/scheduler/state/SideEffect.java
Lines 73 (patched)


I would rename this to avoid confusion. Maybe make it a verb like 
`TRANSITION_TO_LOST`



src/main/java/org/apache/aurora/scheduler/state/StateManagerImpl.java
Lines 402 (patched)


I wondering if having repeated `PARTITIONED` events would be helpful in 
debugging issues, and if it is worth having to deal with the possibility of an 
unbounded TaskEvent list.

I don't really have a strong opinion yet, but I would be curious as to what 
others think.


- Jordan Ly


On Nov. 9, 2017, 12:48 a.m., David McLaughlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/63536/
> ---
> 
> (Updated Nov. 9, 2017, 12:48 a.m.)
> 
> 
> Review request for Aurora, Jordan Ly, Santhosh Kumar Shanmugham, and Bill 
> Farner.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> This is my prototype code for adding partition-awareness to Aurora. There is 
> a proposal document to accompany this here: 
> https://docs.google.com/document/d/1E3GlsVTJLEMAkDWk2_PTxzkRZcapb8nF_5q5AADQI7g/edit#
> 
> I'd like feedback on the high-level approach before adding unit tests, 
> metrics, logging, etc.
> 
> 
> Diffs
> -
> 
>   api/src/main/thrift/org/apache/aurora/gen/api.thrift 
> c869493c06499340d73e1b219e17a0d7d8b5ead9 
>   examples/vagrant/upstart/aurora-scheduler.conf 
> 5ca3caef03b6632cd4dbf47711b1ef183f6a6449 
>   src/main/java/org/apache/aurora/scheduler/base/Conversions.java 
> 33cc012a2cad929b0dd1ce236597b870cfc5aba0 
>   
> src/main/java/org/apache/aurora/scheduler/mesos/CommandLineDriverSettingsModule.java
>  5e83b2acdde7198d16427d4031e9772f78612554 
>   src/main/java/org/apache/aurora/scheduler/state/PartitionManager.java 
> PRE-CREATION 
>   src/main/java/org/apache/aurora/scheduler/state/SideEffect.java 
> b91a0852e968b4aa9d74801601671cb61af3648a 
>   src/main/java/org/apache/aurora/scheduler/state/StateManagerImpl.java 
> 9989ed441cd9bc442e6472768880ce7924c3bdd9 
>   src/main/java/org/apache/aurora/scheduler/state/StateModule.java 
> d72f055749801ee9d6f31f60857cc795d0ed7ab1 
>   src/main/java/org/apache/aurora/scheduler/state/TaskStateMachine.java 
> eb4fe7d78ad1e6ec430c428df527bd0cf3a053c1 
>   src/main/python/apache/aurora/client/cli/jobs.py 
> b79ae56bee0e5692cacf1e66f4a4126b06aaffdc 
>   src/main/python/apache/aurora/config/schema/base.py 
> 18ce826363009e1cc0beac5cce4edf42610d487e 
>   src/main/python/apache/aurora/config/thrift.py 
> bedf8cd6641e1b1a930602791b758d584af4891c 
> 
> 
> Diff: https://reviews.apache.org/r/63536/diff/2/
> 
> 
> Testing
> ---
> 
> Manual testing in Vagrant by stopping and starting the Mesos agent. With 
> three jobs:
> 
> 1) No PartitionPolicy (verified existing behavior of moving from PARTITIONED 
> directly to LOST)
> 2) PartitionPolicy with custom delay_secs (verified sat in PARTITIONED for a 
> while before moving to LOST)
> 3) PartitionPolicy with reschedule=False (verified sat in PARTITIONED 
> indefinitely)
> 
> I also verified tasks are able to transition to various states (back to 
> RUNNING or moving to FAILED, etc.) when you turn the agent back on.
> 
> 
> File Attachments
> 
> 
> Task in PARTITIONED state
>   
> https://reviews.apache.org/media/uploaded/files/2017/11/07/02c7fc72-b11d-4ef9-a86b-914e748cad99__Screen_Shot_2017-11-07_at_11.23.41_AM.png
> Task back into running when partition resolved
>   
> https://reviews.apache.org/media/uploaded/files/2017/11/07/a0413f54-1572-4410-a386-0a22e78fab13__Screen_Shot_2017-11-07_at_11.26.02_AM.png
> Compaction of PARTITIONED cycles (note timestamps)
>   
> https://reviews.apache.org/media/uploaded/files/2017/11/07/edec32e5-b3ec-4fdc-b93f-5449519805ae__Screen_Shot_2017-11-07_at_11.27.47_AM.png
> 
> 
> Thanks,
> 
> David McLaughlin
> 
>

Re: Review Request 63536: Give jobs the ability to determine how to handle partitions by integrating with new Mesos Partition-Aware APIs

2017-11-08 Thread Aurora ReviewBot

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

Master (773d2d6) is red with this patch.
  ./build-support/jenkins/build.sh

   ^
  required: 
String,String,Optional,Amount,boolean,boolean,boolean,Optional
  found: 
String,String,Optional,Amount,boolean,boolean,Optional
  reason: actual and formal argument lists differ in length
/home/jenkins/jenkins-slave/workspace/AuroraBot/src/test/java/org/apache/aurora/scheduler/mesos/CommandLineDriverSettingsModuleTest.java:109:
 error: method buildFrameworkInfo in class CommandLineDriverSettingsModule 
cannot be applied to given types;
Protos.FrameworkInfo info = 
CommandLineDriverSettingsModule.buildFrameworkInfo(
   ^
  required: 
String,String,Optional,Amount,boolean,boolean,boolean,Optional
  found: 
String,String,Optional,Amount,boolean,boolean,Optional
  reason: actual and formal argument lists differ in length
/home/jenkins/jenkins-slave/workspace/AuroraBot/src/test/java/org/apache/aurora/scheduler/mesos/CommandLineDriverSettingsModuleTest.java:125:
 error: method buildFrameworkInfo in class CommandLineDriverSettingsModule 
cannot be applied to given types;
Protos.FrameworkInfo info = 
CommandLineDriverSettingsModule.buildFrameworkInfo(
   ^
  required: 
String,String,Optional,Amount,boolean,boolean,boolean,Optional
  found: 
String,String,Optional,Amount,boolean,boolean,Optional
  reason: actual and formal argument lists differ in length
/home/jenkins/jenkins-slave/workspace/AuroraBot/src/test/java/org/apache/aurora/scheduler/mesos/CommandLineDriverSettingsModuleTest.java:140:
 error: method buildFrameworkInfo in class CommandLineDriverSettingsModule 
cannot be applied to given types;
Protos.FrameworkInfo info = 
CommandLineDriverSettingsModule.buildFrameworkInfo(
   ^
  required: 
String,String,Optional,Amount,boolean,boolean,boolean,Optional
  found: 
String,String,Optional,Amount,boolean,boolean,Optional
  reason: actual and formal argument lists differ in length
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
5 errors
 FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileTestJava'.
> Compilation failed; see the compiler error output for details.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.

* Get more help at https://help.gradle.org

BUILD FAILED in 2m 47s
27 actionable tasks: 21 executed, 6 up-to-date

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

- Aurora ReviewBot

On Nov. 9, 2017, 12:48 a.m., David McLaughlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/63536/
> ---
> 
> (Updated Nov. 9, 2017, 12:48 a.m.)
> 
> 
> Review request for Aurora, Jordan Ly, Santhosh Kumar Shanmugham, and Bill 
> Farner.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> This is my prototype code for adding partition-awareness to Aurora. There is 
> a proposal document to accompany this here: 
> https://docs.google.com/document/d/1E3GlsVTJLEMAkDWk2_PTxzkRZcapb8nF_5q5AADQI7g/edit#
> 
> I'd like feedback on the high-level approach before adding unit tests, 
> metrics, logging, etc.
> 
> 
> Diffs
> -
> 
>   api/src/main/thrift/org/apache/aurora/gen/api.thrift 
> c869493c06499340d73e1b219e17a0d7d8b5ead9 
>   examples/vagrant/upstart/aurora-scheduler.conf 
> 5ca3caef03b6632cd4dbf47711b1ef183f6a6449 
>   src/main/java/org/apache/aurora/scheduler/base/Conversions.java 
> 33cc012a2cad929b0dd1ce236597b870cfc5aba0 
>   
> src/main/java/org/apache/aurora/scheduler/mesos/CommandLineDriverSettingsModule.java
>  5e83b2acdde7198d16427d4031e9772f78612554 
>   src/main/java/org/apache/aurora/scheduler/state/PartitionManager.java 
> PRE-CREATION 
>   src/main/java/org/apache/aurora/scheduler/state/SideEffect.java 
> b91a0852e968b4aa9d74801601671cb61af3648a 
>   src/main/java/org/apache/aurora/scheduler/state/StateManagerImpl.java 
> 9989ed441cd9bc442e6472768880ce7924c3bdd9 
>   src/main/java/org/apache/aurora/scheduler/state/StateModule.java 
> d72f055749801ee9d6f31f60857cc795d0ed7ab1 
>   src/main/java/org/apache/aurora/scheduler/state/TaskStateMachine.java 
> eb4fe7d78ad1e6ec430c428df527bd0cf3a053c1 
>   src/main/python/apache/aurora/client/cli/jobs.py 
>

Re: Review Request 63536: Give jobs the ability to determine how to handle partitions by integrating with new Mesos Partition-Aware APIs

2017-11-08 Thread David McLaughlin


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

(Updated Nov. 9, 2017, 12:48 a.m.)


Review request for Aurora, Jordan Ly, Santhosh Kumar Shanmugham, and Bill 
Farner.


Changes
---

Added logic to handle failovers / dealing with timer race conditions.


Repository: aurora


Description
---

This is my prototype code for adding partition-awareness to Aurora. There is a 
proposal document to accompany this here: 
https://docs.google.com/document/d/1E3GlsVTJLEMAkDWk2_PTxzkRZcapb8nF_5q5AADQI7g/edit#

I'd like feedback on the high-level approach before adding unit tests, metrics, 
logging, etc.


Diffs (updated)
-

  api/src/main/thrift/org/apache/aurora/gen/api.thrift 
c869493c06499340d73e1b219e17a0d7d8b5ead9 
  examples/vagrant/upstart/aurora-scheduler.conf 
5ca3caef03b6632cd4dbf47711b1ef183f6a6449 
  src/main/java/org/apache/aurora/scheduler/base/Conversions.java 
33cc012a2cad929b0dd1ce236597b870cfc5aba0 
  
src/main/java/org/apache/aurora/scheduler/mesos/CommandLineDriverSettingsModule.java
 5e83b2acdde7198d16427d4031e9772f78612554 
  src/main/java/org/apache/aurora/scheduler/state/PartitionManager.java 
PRE-CREATION 
  src/main/java/org/apache/aurora/scheduler/state/SideEffect.java 
b91a0852e968b4aa9d74801601671cb61af3648a 
  src/main/java/org/apache/aurora/scheduler/state/StateManagerImpl.java 
9989ed441cd9bc442e6472768880ce7924c3bdd9 
  src/main/java/org/apache/aurora/scheduler/state/StateModule.java 
d72f055749801ee9d6f31f60857cc795d0ed7ab1 
  src/main/java/org/apache/aurora/scheduler/state/TaskStateMachine.java 
eb4fe7d78ad1e6ec430c428df527bd0cf3a053c1 
  src/main/python/apache/aurora/client/cli/jobs.py 
b79ae56bee0e5692cacf1e66f4a4126b06aaffdc 
  src/main/python/apache/aurora/config/schema/base.py 
18ce826363009e1cc0beac5cce4edf42610d487e 
  src/main/python/apache/aurora/config/thrift.py 
bedf8cd6641e1b1a930602791b758d584af4891c 


Diff: https://reviews.apache.org/r/63536/diff/2/

Changes: https://reviews.apache.org/r/63536/diff/1-2/


Testing
---

Manual testing in Vagrant by stopping and starting the Mesos agent. With three 
jobs:

1) No PartitionPolicy (verified existing behavior of moving from PARTITIONED 
directly to LOST)
2) PartitionPolicy with custom delay_secs (verified sat in PARTITIONED for a 
while before moving to LOST)
3) PartitionPolicy with reschedule=False (verified sat in PARTITIONED 
indefinitely)

I also verified tasks are able to transition to various states (back to RUNNING 
or moving to FAILED, etc.) when you turn the agent back on.


File Attachments


Task in PARTITIONED state
  
https://reviews.apache.org/media/uploaded/files/2017/11/07/02c7fc72-b11d-4ef9-a86b-914e748cad99__Screen_Shot_2017-11-07_at_11.23.41_AM.png
Task back into running when partition resolved
  
https://reviews.apache.org/media/uploaded/files/2017/11/07/a0413f54-1572-4410-a386-0a22e78fab13__Screen_Shot_2017-11-07_at_11.26.02_AM.png
Compaction of PARTITIONED cycles (note timestamps)
  
https://reviews.apache.org/media/uploaded/files/2017/11/07/edec32e5-b3ec-4fdc-b93f-5449519805ae__Screen_Shot_2017-11-07_at_11.27.47_AM.png


Thanks,

David McLaughlin

Re: Review Request 63688: Fix tutorial test script

2017-11-08 Thread Jordan Ly


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


Ship it!




Ship It!

- Jordan Ly


On Nov. 8, 2017, 11:58 p.m., David McLaughlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/63688/
> ---
> 
> (Updated Nov. 8, 2017, 11:58 p.m.)
> 
> 
> Review request for Aurora, Jordan Ly, Stephan Erb, and Bill Farner.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> Update script to reflect the contents of tutorial.md
> 
> 
> Diffs
> -
> 
>   examples/vagrant/test_tutorial.sh ae06fd2a768134d530561cfbae65f40c3c21cfab 
> 
> 
> Diff: https://reviews.apache.org/r/63688/diff/1/
> 
> 
> Testing
> ---
> 
> $ examples/vagrant/test_tutorial.sh 
> Checking scheduler health...\c
> PASS
> Checking observer health...\c
> PASS
> Checking master health...\c
> PASS
> Checking slave health...\c
> PASS
> Running create command...\c
> PASS
> Waiting to observe FAILED task...\c
> PASS
> Running update command...\c
> PASS
> Waiting to observe RUNNING task...\c
> PASS
> Running killall command...\c
> PASS
> 
> 
> Thanks,
> 
> David McLaughlin
> 
>

Re: Review Request 63536: Give jobs the ability to determine how to handle partitions by integrating with new Mesos Partition-Aware APIs

2017-11-08 Thread David McLaughlin



> On Nov. 7, 2017, 11:36 p.m., Stephan Erb wrote:
> > src/main/java/org/apache/aurora/scheduler/state/PartitionManager.java
> > Lines 38-42 (patched)
> > 
> >
> > On the other hand, this would be consistent from the user perspective. 
> > A user only sees the compacted task events with a single RUNNING to 
> > PARTITIONED transition. 
> > 
> > If we cancel the future, he might wonder why the task does not end up 
> > as LOST.
> 
> David McLaughlin wrote:
> Maybe it's not clear without tests - but this timer is responsible for 
> moving from PARTITIONED -> LOST after a specified delay. This comment is 
> concerned about the user saying "give up on a partition after 15 minutes" and 
> then a task moving from RUNNING -> PARTITIONED -> RUNNING -> PARTITIONED 
> within a 15 minute window. When the task transitions back to RUNNING the 
> first time, the user would expect the timer to be reset.
> 
> David McLaughlin wrote:
> It also just occured to me this timer won't survive a restart. So if I 
> want to use this event-driven model, then I'll need to plug into the storage 
> restore operation too.

Jordan pointed out that it will survive a restart as the storage layer sends 
all the events on recovery (which I should have remembered from WebHooks!). So 
I just need to check each state change for isTransition and then change delay 
to depend on the latest task event time.


- David


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


On Nov. 7, 2017, 7:28 p.m., David McLaughlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/63536/
> ---
> 
> (Updated Nov. 7, 2017, 7:28 p.m.)
> 
> 
> Review request for Aurora, Jordan Ly, Santhosh Kumar Shanmugham, and Bill 
> Farner.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> This is my prototype code for adding partition-awareness to Aurora. There is 
> a proposal document to accompany this here: 
> https://docs.google.com/document/d/1E3GlsVTJLEMAkDWk2_PTxzkRZcapb8nF_5q5AADQI7g/edit#
> 
> I'd like feedback on the high-level approach before adding unit tests, 
> metrics, logging, etc.
> 
> 
> Diffs
> -
> 
>   api/src/main/thrift/org/apache/aurora/gen/api.thrift 
> c869493c06499340d73e1b219e17a0d7d8b5ead9 
>   examples/vagrant/upstart/aurora-scheduler.conf 
> 5ca3caef03b6632cd4dbf47711b1ef183f6a6449 
>   src/main/java/org/apache/aurora/scheduler/base/Conversions.java 
> 33cc012a2cad929b0dd1ce236597b870cfc5aba0 
>   
> src/main/java/org/apache/aurora/scheduler/mesos/CommandLineDriverSettingsModule.java
>  5e83b2acdde7198d16427d4031e9772f78612554 
>   src/main/java/org/apache/aurora/scheduler/state/PartitionManager.java 
> PRE-CREATION 
>   src/main/java/org/apache/aurora/scheduler/state/SideEffect.java 
> b91a0852e968b4aa9d74801601671cb61af3648a 
>   src/main/java/org/apache/aurora/scheduler/state/StateManagerImpl.java 
> 9989ed441cd9bc442e6472768880ce7924c3bdd9 
>   src/main/java/org/apache/aurora/scheduler/state/StateModule.java 
> d72f055749801ee9d6f31f60857cc795d0ed7ab1 
>   src/main/java/org/apache/aurora/scheduler/state/TaskStateMachine.java 
> eb4fe7d78ad1e6ec430c428df527bd0cf3a053c1 
>   src/main/python/apache/aurora/client/cli/jobs.py 
> b79ae56bee0e5692cacf1e66f4a4126b06aaffdc 
>   src/main/python/apache/aurora/config/schema/base.py 
> 18ce826363009e1cc0beac5cce4edf42610d487e 
>   src/main/python/apache/aurora/config/thrift.py 
> bedf8cd6641e1b1a930602791b758d584af4891c 
> 
> 
> Diff: https://reviews.apache.org/r/63536/diff/1/
> 
> 
> Testing
> ---
> 
> Manual testing in Vagrant by stopping and starting the Mesos agent. With 
> three jobs:
> 
> 1) No PartitionPolicy (verified existing behavior of moving from PARTITIONED 
> directly to LOST)
> 2) PartitionPolicy with custom delay_secs (verified sat in PARTITIONED for a 
> while before moving to LOST)
> 3) PartitionPolicy with reschedule=False (verified sat in PARTITIONED 
> indefinitely)
> 
> I also verified tasks are able to transition to various states (back to 
> RUNNING or moving to FAILED, etc.) when you turn the agent back on.
> 
> 
> File Attachments
> 
> 
> Task in PARTITIONED state
>   
> https://reviews.apache.org/media/uploaded/files/2017/11/07/02c7fc72-b11d-4ef9-a86b-914e748cad99__Screen_Shot_2017-11-07_at_11.23.41_AM.png
> Task back into running when partition resolved
>   
> https://reviews.apache.org/media/uploaded/files/2017/11/07/a0413f54-1572-4410-a386-0a22e78fab13__Screen_Shot_2017-11-07_at_11.26.02_AM.png
> Compaction of PARTITIONED cycles (note timestamps)
>   
>

Re: Review Request 63688: Fix tutorial test script

2017-11-08 Thread Aurora ReviewBot


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


Ship it!




Master (5dfe51c) is green with this patch.
  ./build-support/jenkins/build.sh

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

- Aurora ReviewBot


On Nov. 8, 2017, 11:58 p.m., David McLaughlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/63688/
> ---
> 
> (Updated Nov. 8, 2017, 11:58 p.m.)
> 
> 
> Review request for Aurora, Jordan Ly, Stephan Erb, and Bill Farner.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> Update script to reflect the contents of tutorial.md
> 
> 
> Diffs
> -
> 
>   examples/vagrant/test_tutorial.sh ae06fd2a768134d530561cfbae65f40c3c21cfab 
> 
> 
> Diff: https://reviews.apache.org/r/63688/diff/1/
> 
> 
> Testing
> ---
> 
> $ examples/vagrant/test_tutorial.sh 
> Checking scheduler health...\c
> PASS
> Checking observer health...\c
> PASS
> Checking master health...\c
> PASS
> Checking slave health...\c
> PASS
> Running create command...\c
> PASS
> Waiting to observe FAILED task...\c
> PASS
> Running update command...\c
> PASS
> Waiting to observe RUNNING task...\c
> PASS
> Running killall command...\c
> PASS
> 
> 
> Thanks,
> 
> David McLaughlin
> 
>

Review Request 63688: Fix tutorial test script

2017-11-08 Thread David McLaughlin


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

Review request for Aurora, Jordan Ly, Stephan Erb, and Bill Farner.


Repository: aurora


Description
---

Update script to reflect the contents of tutorial.md


Diffs
-

  examples/vagrant/test_tutorial.sh ae06fd2a768134d530561cfbae65f40c3c21cfab 


Diff: https://reviews.apache.org/r/63688/diff/1/


Testing
---

$ examples/vagrant/test_tutorial.sh 
Checking scheduler health...\c
PASS
Checking observer health...\c
PASS
Checking master health...\c
PASS
Checking slave health...\c
PASS
Running create command...\c
PASS
Waiting to observe FAILED task...\c
PASS
Running update command...\c
PASS
Waiting to observe RUNNING task...\c
PASS
Running killall command...\c
PASS


Thanks,

David McLaughlin

Re: Review Request 63685: RFC: Use new scheduler UI as landing page

2017-11-08 Thread Aurora ReviewBot


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



Master (5dfe51c) is green with this patch.
  ./build-support/jenkins/build.sh

However, it appears that it might lack test coverage.

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

- Aurora ReviewBot


On Nov. 8, 2017, 10:32 p.m., Stephan Erb wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/63685/
> ---
> 
> (Updated Nov. 8, 2017, 10:32 p.m.)
> 
> 
> Review request for Aurora, David McLaughlin and Joshua Cohen.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> Is this something the community would be interested in?
> 
> Known issues in this minimal viable prototype:
> 
> * I did not manage to convince Jetty to perform the redirecting. Using the 
> HTML feels hacky but works.
> * An operator will have difficulties to navigate to /admin of a non-leading 
> instance. In particular if there is no leader at all.
> 
> 
> Diffs
> -
> 
>   src/main/java/org/apache/aurora/scheduler/http/JettyServerModule.java 
> 0f8528c3403b5f51f082aa54c16358f7568f439a 
>   src/main/resources/scheduler/assets/index.html 
> 533091395547a6b067dbf5f53e42a13a560971da 
>   ui/src/main/js/components/Navigation.js 
> 50881a9914cee2812807624cd28f24fa64207296 
>   ui/src/main/js/index.js 9f94d4bd6f649d74bdd9c3aa99783e01cae25d93 
>   ui/src/main/js/pages/Admin.js PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/63685/diff/1/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Screen Shot 2017-11-08 at 23.18.06.png
>   
> https://reviews.apache.org/media/uploaded/files/2017/11/08/80ae2c5f-e431-4f86-8811-13bfe6a8627b__Screen_Shot_2017-11-08_at_23.18.06.png
> Screen Shot 2017-11-08 at 23.18.20.png
>   
> https://reviews.apache.org/media/uploaded/files/2017/11/08/9fb0f2e0-49c9-427f-8b84-d3d1fc057a59__Screen_Shot_2017-11-08_at_23.18.20.png
> 
> 
> Thanks,
> 
> Stephan Erb
> 
>

Review Request 63685: RFC: Use new scheduler UI as landing page

2017-11-08 Thread Stephan Erb


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

Review request for Aurora, David McLaughlin and Joshua Cohen.


Repository: aurora


Description
---

Is this something the community would be interested in?

Known issues in this minimal viable prototype:

* I did not manage to convince Jetty to perform the redirecting. Using the HTML 
feels hacky but works.
* An operator will have difficulties to navigate to /admin of a non-leading 
instance. In particular if there is no leader at all.


Diffs
-

  src/main/java/org/apache/aurora/scheduler/http/JettyServerModule.java 
0f8528c3403b5f51f082aa54c16358f7568f439a 
  src/main/resources/scheduler/assets/index.html 
533091395547a6b067dbf5f53e42a13a560971da 
  ui/src/main/js/components/Navigation.js 
50881a9914cee2812807624cd28f24fa64207296 
  ui/src/main/js/index.js 9f94d4bd6f649d74bdd9c3aa99783e01cae25d93 
  ui/src/main/js/pages/Admin.js PRE-CREATION 


Diff: https://reviews.apache.org/r/63685/diff/1/


Testing
---


File Attachments


Screen Shot 2017-11-08 at 23.18.06.png
  
https://reviews.apache.org/media/uploaded/files/2017/11/08/80ae2c5f-e431-4f86-8811-13bfe6a8627b__Screen_Shot_2017-11-08_at_23.18.06.png
Screen Shot 2017-11-08 at 23.18.20.png
  
https://reviews.apache.org/media/uploaded/files/2017/11/08/9fb0f2e0-49c9-427f-8b84-d3d1fc057a59__Screen_Shot_2017-11-08_at_23.18.20.png


Thanks,

Stephan Erb

Re: Review Request 63670: Add a test for storage durability

2017-11-08 Thread Jordan Ly


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


Ship it!





src/test/java/org/apache/aurora/scheduler/storage/log/DurableStorageTest.java
Lines 59 (patched)


I might name this NonVolatileStorageTest for consistency, and since I 
believe you are essentially only testing this interface.


- Jordan Ly


On Nov. 8, 2017, 4:13 p.m., Bill Farner wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/63670/
> ---
> 
> (Updated Nov. 8, 2017, 4:13 p.m.)
> 
> 
> Review request for Aurora and Jordan Ly.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> Introduces a new test that validates the durability of the storage system as 
> a whole.  Since we cannot count on loading the mesos JNI lib, a `FakeLog` is 
> introduced to represent the durable layer.  Additionally, the high-level 
> nature of this test should allow it to serve as a conformance test when new 
> storage layer implementations are added.
> 
> I also removed the `Comparable` interface from `Log.Position`, as it was 
> never used.
> 
> 
> Diffs
> -
> 
>   src/main/java/org/apache/aurora/scheduler/log/Log.java 
> dc77eb435e5f8fdce56727a2f679e8e1907e977c 
>   src/main/java/org/apache/aurora/scheduler/log/mesos/MesosLog.java 
> 21855e184fe20dc339713978b32344b6950701ec 
>   src/test/java/org/apache/aurora/scheduler/app/SchedulerIT.java 
> 67a0d5a7da90dc01b7a962c2f21730b4be06895a 
>   src/test/java/org/apache/aurora/scheduler/log/mesos/MesosLogTest.java 
> f142f545799d64f9352b0ac6c51942eedf5e9ced 
>   
> src/test/java/org/apache/aurora/scheduler/storage/log/DurableStorageTest.java 
> PRE-CREATION 
>   src/test/java/org/apache/aurora/scheduler/storage/log/FakeLog.java 
> PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/63670/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bill Farner
> 
>

Re: Review Request 63670: Add a test for storage durability

2017-11-08 Thread Aurora ReviewBot


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


Ship it!




Master (5dfe51c) is green with this patch.
  ./build-support/jenkins/build.sh

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

- Aurora ReviewBot


On Nov. 8, 2017, 4:13 p.m., Bill Farner wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/63670/
> ---
> 
> (Updated Nov. 8, 2017, 4:13 p.m.)
> 
> 
> Review request for Aurora and Jordan Ly.
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> Introduces a new test that validates the durability of the storage system as 
> a whole.  Since we cannot count on loading the mesos JNI lib, a `FakeLog` is 
> introduced to represent the durable layer.  Additionally, the high-level 
> nature of this test should allow it to serve as a conformance test when new 
> storage layer implementations are added.
> 
> I also removed the `Comparable` interface from `Log.Position`, as it was 
> never used.
> 
> 
> Diffs
> -
> 
>   src/main/java/org/apache/aurora/scheduler/log/Log.java 
> dc77eb435e5f8fdce56727a2f679e8e1907e977c 
>   src/main/java/org/apache/aurora/scheduler/log/mesos/MesosLog.java 
> 21855e184fe20dc339713978b32344b6950701ec 
>   src/test/java/org/apache/aurora/scheduler/app/SchedulerIT.java 
> 67a0d5a7da90dc01b7a962c2f21730b4be06895a 
>   src/test/java/org/apache/aurora/scheduler/log/mesos/MesosLogTest.java 
> f142f545799d64f9352b0ac6c51942eedf5e9ced 
>   
> src/test/java/org/apache/aurora/scheduler/storage/log/DurableStorageTest.java 
> PRE-CREATION 
>   src/test/java/org/apache/aurora/scheduler/storage/log/FakeLog.java 
> PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/63670/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bill Farner
> 
>

Review Request 63670: Add a test for storage durability

2017-11-08 Thread Bill Farner


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

Review request for Aurora and Jordan Ly.


Repository: aurora


Description
---

Introduces a new test that validates the durability of the storage system as a 
whole.  Since we cannot count on loading the mesos JNI lib, a `FakeLog` is 
introduced to represent the durable layer.  Additionally, the high-level nature 
of this test should allow it to serve as a conformance test when new storage 
layer implementations are added.

I also removed the `Comparable` interface from `Log.Position`, as it was never 
used.


Diffs
-

  src/main/java/org/apache/aurora/scheduler/log/Log.java 
dc77eb435e5f8fdce56727a2f679e8e1907e977c 
  src/main/java/org/apache/aurora/scheduler/log/mesos/MesosLog.java 
21855e184fe20dc339713978b32344b6950701ec 
  src/test/java/org/apache/aurora/scheduler/app/SchedulerIT.java 
67a0d5a7da90dc01b7a962c2f21730b4be06895a 
  src/test/java/org/apache/aurora/scheduler/log/mesos/MesosLogTest.java 
f142f545799d64f9352b0ac6c51942eedf5e9ced 
  src/test/java/org/apache/aurora/scheduler/storage/log/DurableStorageTest.java 
PRE-CREATION 
  src/test/java/org/apache/aurora/scheduler/storage/log/FakeLog.java 
PRE-CREATION 


Diff: https://reviews.apache.org/r/63670/diff/1/


Testing
---


Thanks,

Bill Farner

Re: Review Request 60942: Remove task level resource fields from thrift interface and db

2017-11-08 Thread Aurora ReviewBot


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


Ship it!




Master (5dfe51c) is green with this patch.
  ./build-support/jenkins/build.sh

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

- Aurora ReviewBot


On Nov. 8, 2017, 2:37 p.m., Nicolás Donatucci wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60942/
> ---
> 
> (Updated Nov. 8, 2017, 2:37 p.m.)
> 
> 
> Review request for Aurora, Joshua Cohen, Stephan Erb, and Zameer Manji.
> 
> 
> Bugs: AURORA-1707
> https://issues.apache.org/jira/browse/AURORA-1707
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> Removed task level resource fields from the DB and the thrift-API.
> To do this, a new DB migration was added. When upgrading, it just drops the 
> task level resource fields. When downgrading, it creates the fields again and 
> populates them with information from the task_resource table.
> 
> IMPORTANT: Having an issue when going from 0.18.0 to patched version and then 
> to 0.18.0 again.
> 
> "E1106 19:16:28.752 [LeaderSelector-0, SchedulerLifecycle] Caught unchecked 
> exception: com.google.common.util.concurrent.UncheckedExecutionException: 
> java.lang.IllegalArgumentException: Multiple entries with same key"
> 
> [4:23] 
> org.apache.aurora.scheduler.storage.db.views.DbTaskConfig@182dcd47. To index 
> multiple values under a key, use Multimaps.index.
> 
> Will investigate more, but I'm not really getting what is going on.
> 
> Issue Related: AURORA-1707
> 
> 
> Diffs
> -
> 
>   RELEASE-NOTES.md 5122c49354811bdb53bd5a0febb29c5d8a736b0d 
>   api/src/main/thrift/org/apache/aurora/gen/api.thrift 
> c869493c06499340d73e1b219e17a0d7d8b5ead9 
>   src/main/java/org/apache/aurora/scheduler/base/TaskTestUtil.java 
> 7c223eae69503fe1d5bf34c430438637abcbcb9b 
>   src/main/java/org/apache/aurora/scheduler/storage/db/TaskConfigManager.java 
> d2eb6aa6e4a155b2d28debab2ca10dfc76d57213 
>   src/main/java/org/apache/aurora/scheduler/storage/db/TaskConfigMapper.java 
> cda55c55680a19ed421299a8949299b21949787b 
>   
> src/main/java/org/apache/aurora/scheduler/storage/db/migration/V004_CreateTaskResourceTable.java
>  af106a8a9ee8c14122e98bcc0ec44b616f21d61f 
>   
> src/main/java/org/apache/aurora/scheduler/storage/db/views/DbTaskConfig.java 
> 138cd5316adc73eed24fc7accc53885dd5d5bee5 
>   src/main/python/apache/aurora/client/cli/diff_formatter.py 
> 78717774aa3fbaf83a5fb850bc9f9f4a4038d70f 
>   src/main/python/apache/aurora/client/cli/jobs.py 
> b79ae56bee0e5692cacf1e66f4a4126b06aaffdc 
>   
> src/main/resources/org/apache/aurora/scheduler/storage/db/TaskConfigMapper.xml
>  5422183e4a1fe122fc0e1aa871aa75ae102e322d 
>   src/main/resources/org/apache/aurora/scheduler/storage/db/schema.sql 
> 7a86f47af67adb3e488381d30ddf424549deefbc 
>   src/test/java/org/apache/aurora/scheduler/http/TestUtils.java 
> 689482c9f6c49bcca781834566edeb975d2f3af2 
>   
> src/test/java/org/apache/aurora/scheduler/storage/db/RowGarbageCollectorTest.java
>  74c9d1d2fba94971106c148ac76d5a76dab6a7b4 
>   src/test/java/org/apache/aurora/scheduler/thrift/Fixtures.java 
> 43e32eede27bbf26363a3fd1ca34ffe6f8c01a73 
>   
> src/test/java/org/apache/aurora/scheduler/updater/UpdateAgentReserverImplTest.java
>  1bc2a778ad3f1543a055023f9ec3fe9e4a9523e3 
>   src/test/python/apache/aurora/client/cli/test_status.py 
> b0b7f96d8148f0dd1f6f45d1c5c6f830cabcfd5d 
>   src/test/python/apache/aurora/client/cli/util.py 
> 476b8c2951f315db0b9983bb8fbed0d7efc155aa 
>   src/test/python/apache/aurora/config/test_resources.py 
> 25a20f0b702189744a26b85053db34c37ff5b03c 
> 
> 
> Diff: https://reviews.apache.org/r/60942/diff/9/
> 
> 
> Testing
> ---
> 
> src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh
> 
> 1 - Created a new VM with a fresh Aurora 0.18.0, ran the tests so that the db 
> would have something. Then upgraded to patched version and ran the tests 
> again. Everything worked and task level resource fields were no longer there.
> 2 - Created a new VM with a fresh patched version, ran the tests so that the 
> db would have something. Then downgraded to 0.18.0 and ran the tests again. 
> Everything worked and task level resources were there, with the correct 
> backfilled values.
> 
> 
> Thanks,
> 
> Nicolás Donatucci
> 
>

Re: Review Request 60942: Remove task level resource fields from thrift interface and db

2017-11-08 Thread Nicolás Donatucci


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

(Updated Nov. 8, 2017, 2:37 p.m.)


Review request for Aurora, Joshua Cohen, Stephan Erb, and Zameer Manji.


Changes
---

Removed DB Migration


Bugs: AURORA-1707
https://issues.apache.org/jira/browse/AURORA-1707


Repository: aurora


Description (updated)
---

Removed task level resource fields from the DB and the thrift-API.
To do this, a new DB migration was added. When upgrading, it just drops the 
task level resource fields. When downgrading, it creates the fields again and 
populates them with information from the task_resource table.

IMPORTANT: Having an issue when going from 0.18.0 to patched version and then 
to 0.18.0 again.

"E1106 19:16:28.752 [LeaderSelector-0, SchedulerLifecycle] Caught unchecked 
exception: com.google.common.util.concurrent.UncheckedExecutionException: 
java.lang.IllegalArgumentException: Multiple entries with same key"

[4:23] 
org.apache.aurora.scheduler.storage.db.views.DbTaskConfig@182dcd47. To index 
multiple values under a key, use Multimaps.index.

Will investigate more, but I'm not really getting what is going on.

Issue Related: AURORA-1707


Diffs (updated)
-

  RELEASE-NOTES.md 5122c49354811bdb53bd5a0febb29c5d8a736b0d 
  api/src/main/thrift/org/apache/aurora/gen/api.thrift 
c869493c06499340d73e1b219e17a0d7d8b5ead9 
  src/main/java/org/apache/aurora/scheduler/base/TaskTestUtil.java 
7c223eae69503fe1d5bf34c430438637abcbcb9b 
  src/main/java/org/apache/aurora/scheduler/storage/db/TaskConfigManager.java 
d2eb6aa6e4a155b2d28debab2ca10dfc76d57213 
  src/main/java/org/apache/aurora/scheduler/storage/db/TaskConfigMapper.java 
cda55c55680a19ed421299a8949299b21949787b 
  
src/main/java/org/apache/aurora/scheduler/storage/db/migration/V004_CreateTaskResourceTable.java
 af106a8a9ee8c14122e98bcc0ec44b616f21d61f 
  src/main/java/org/apache/aurora/scheduler/storage/db/views/DbTaskConfig.java 
138cd5316adc73eed24fc7accc53885dd5d5bee5 
  src/main/python/apache/aurora/client/cli/diff_formatter.py 
78717774aa3fbaf83a5fb850bc9f9f4a4038d70f 
  src/main/python/apache/aurora/client/cli/jobs.py 
b79ae56bee0e5692cacf1e66f4a4126b06aaffdc 
  
src/main/resources/org/apache/aurora/scheduler/storage/db/TaskConfigMapper.xml 
5422183e4a1fe122fc0e1aa871aa75ae102e322d 
  src/main/resources/org/apache/aurora/scheduler/storage/db/schema.sql 
7a86f47af67adb3e488381d30ddf424549deefbc 
  src/test/java/org/apache/aurora/scheduler/http/TestUtils.java 
689482c9f6c49bcca781834566edeb975d2f3af2 
  
src/test/java/org/apache/aurora/scheduler/storage/db/RowGarbageCollectorTest.java
 74c9d1d2fba94971106c148ac76d5a76dab6a7b4 
  src/test/java/org/apache/aurora/scheduler/thrift/Fixtures.java 
43e32eede27bbf26363a3fd1ca34ffe6f8c01a73 
  
src/test/java/org/apache/aurora/scheduler/updater/UpdateAgentReserverImplTest.java
 1bc2a778ad3f1543a055023f9ec3fe9e4a9523e3 
  src/test/python/apache/aurora/client/cli/test_status.py 
b0b7f96d8148f0dd1f6f45d1c5c6f830cabcfd5d 
  src/test/python/apache/aurora/client/cli/util.py 
476b8c2951f315db0b9983bb8fbed0d7efc155aa 
  src/test/python/apache/aurora/config/test_resources.py 
25a20f0b702189744a26b85053db34c37ff5b03c 


Diff: https://reviews.apache.org/r/60942/diff/9/

Changes: https://reviews.apache.org/r/60942/diff/8-9/


Testing
---

src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh

1 - Created a new VM with a fresh Aurora 0.18.0, ran the tests so that the db 
would have something. Then upgraded to patched version and ran the tests again. 
Everything worked and task level resource fields were no longer there.
2 - Created a new VM with a fresh patched version, ran the tests so that the db 
would have something. Then downgraded to 0.18.0 and ran the tests again. 
Everything worked and task level resources were there, with the correct 
backfilled values.


Thanks,

Nicolás Donatucci

Re: Review Request 63685: RFC: Use new scheduler UI as landing page

Re: Review Request 63685: RFC: Use new scheduler UI as landing page

Re: Review Request 63536: Give jobs the ability to determine how to handle partitions by integrating with new Mesos Partition-Aware APIs

Re: Review Request 63536: Give jobs the ability to determine how to handle partitions by integrating with new Mesos Partition-Aware APIs

Re: Review Request 63536: Give jobs the ability to determine how to handle partitions by integrating with new Mesos Partition-Aware APIs

Re: Review Request 63688: Fix tutorial test script

Re: Review Request 63536: Give jobs the ability to determine how to handle partitions by integrating with new Mesos Partition-Aware APIs

Re: Review Request 63688: Fix tutorial test script

Review Request 63688: Fix tutorial test script

Re: Review Request 63685: RFC: Use new scheduler UI as landing page

Review Request 63685: RFC: Use new scheduler UI as landing page

Re: Review Request 63670: Add a test for storage durability

Re: Review Request 63670: Add a test for storage durability

Review Request 63670: Add a test for storage durability

Re: Review Request 60942: Remove task level resource fields from thrift interface and db

Re: Review Request 60942: Remove task level resource fields from thrift interface and db

16 matches

Site Navigation

Mail list logo

Footer information