Mailing-List: contact reviews-help@aurora.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: reviews@aurora.incubator.apache.org
Content-Type: multipart/alternative;
 boundary="===============0408613137053893812=="
MIME-Version: 1.0
Subject: Re: Review Request 25741: Remove INSTANCE_ADDED and INSTANCE_REMOVED
 states.
From: "Bill Farner" <wfarner@apache.org>
To: "Maxim Khutornenko" <maxim@apache.org>,
 "David McLaughlin" <david@dmclaughlin.com>
Cc: "Bill Farner" <wfarner@apache.org>,
 "Aurora" <reviews@aurora.incubator.apache.org>
Date: Wed, 17 Sep 2014 17:54:08 -0000
Message-ID: <20140917175408.7800.56824@reviews.apache.org>
Auto-Submitted: auto-generated
Sender: "Bill Farner" <noreply@reviews.apache.org>
References: <20140917172109.7803.60153@reviews.apache.org>
In-Reply-To: <20140917172109.7803.60153@reviews.apache.org>
Reply-To: "Bill Farner" <wfarner@apache.org>

--===============0408613137053893812==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


> 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.

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.


- 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
> 
>


--===============0408613137053893812==--