aurora-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Farner" <wfar...@apache.org>
Subject Re: Review Request 25741: Remove INSTANCE_ADDED and INSTANCE_REMOVED states.
Date Wed, 17 Sep 2014 18:23:43 GMT


> On Sept. 17, 2014, 5:21 p.m., David McLaughlin wrote:
> > Does removing an instance take any significant amount of time? Can it fail? The
concern is we'll be showing 100% progress but the update is still running when reducing the
instance count.
> 
> Bill Farner wrote:
>     Depends on your definition of significant.  It does take a non-deterministic amount
of time, since we transition to KILLING and await to see that the task is gone.  It can _sort
of_ fail, but not in a way that we will record an instance failure AFAICT.  However, i think
the behavior of ACTING -> FINISHED even in removal is nice as it matches two-step nature
of the operation.
> 
> David McLaughlin wrote:
>     I see, so the new behaviour is that in both scenarios the instance would end up in
INSTANCE_UPDATED state? And then the client infers whether it was added or removed based on
the instance count delta?

Effectively, yes.  The states communicate "acting" and "finished" along with direction (updating
or rollback), and the caller has the information to determine what the outcome looks like
(config change, added, removed).


- Bill


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


On Sept. 17, 2014, 5:15 p.m., Bill Farner wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25741/
> -----------------------------------------------------------
> 
> (Updated Sept. 17, 2014, 5:15 p.m.)
> 
> 
> Review request for Aurora, David McLaughlin and Maxim Khutornenko.
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> Since we're changing fields in `JobUpdateConfiguration` (being renamed to `JobUpdateInstructions`)
to represent the delta incurred by a job update (AURORA-718), i believe we can remove these
two states, as addition/removal can be inferred from the delta.
> 
> Furthermore, this allows the job updater's internal state machine to translate directly
into the remaining `JobUpdateActions`, and hides details of the non-atomic actions necessary
to move an instance from state A to state B.
> 
> 
> Diffs
> -----
> 
>   src/main/resources/org/apache/aurora/scheduler/http/ui/js/services.js 5d6299f9de6eccd0f1332e11d57dfb910d956011

>   src/main/thrift/org/apache/aurora/gen/api.thrift 3d0beeaed74aafcec0e24725f443e53a67f6c3a0

>   src/test/java/org/apache/aurora/scheduler/storage/db/DBJobUpdateStoreTest.java e09caa63bc0150d7109cb237e80b9efee441dded

>   src/test/java/org/apache/aurora/scheduler/storage/log/LogStorageTest.java ca990e73d80e8456e71a97f0bdd0b6f4530d0135

> 
> Diff: https://reviews.apache.org/r/25741/diff/
> 
> 
> Testing
> -------
> 
> ./gradlew build -Pq
> 
> 
> Thanks,
> 
> Bill Farner
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message