aurora-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maxim Khutornenko" <ma...@apache.org>
Subject Re: Review Request 19888: Prepare to store UNKNOWN state.
Date Tue, 01 Apr 2014 23:19:17 GMT


> On April 1, 2014, 10:43 p.m., Bill Farner wrote:
> > Isn't a StorageBackfill what you're after here?  Rewrite tasks in the UNKNOWN state
to a more appropriate state?
> 
> Maxim Khutornenko wrote:
>     The StorageBackfill is a much more invasive approach, which is not really required
here. Besides, rewriting state would mess up the task events and show something like FINISHED
-> UNKNOWN -> FINISHED. Trying to minimize the impact here.
> 
> Bill Farner wrote:
>     I find changing state machine logic more invasive, actually.  This will impact other
areas of the system.  For example, HistoryPruner will be unable to purge these tasks because
UNKNOWN is not a TERMINAL_STATE.
>     
>     However, with a backfill operation, you could flip a task in UNKNOWN back to the
previous state, and delete the transition event to UNKNOWN (i.e. this doesn't need to go through
the state machine).
> 
> Maxim Khutornenko wrote:
>     Rewriting the events would result in a broken UI sandbox link until the history pruner
acts on it, whereas in my case UNKNOWN tasks were not shown in the UI. Anyway, I am ok with
the backfill approach.
> 
> Bill Farner wrote:
>     Maybe i'm confused about the state of master, but isn't what you describe the longstanding
behavior?

Not really. The current behavior is to follow up with DELETE on the transition to UNKNOWN.
That removes the item completely from the UI. In my case, that behavior would remain unchanged
as UNKNOWN tasks are not pulled into the UI (cause they are neither ACTIVE nor TERMINAL).


With the backfill, the UNKNOWN becomes terminal and hence visible again but the sandbox is
already gone. The link would be broken for an hour or two until the history pruner picks it
up.


- Maxim


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


On April 1, 2014, 9:52 p.m., Maxim Khutornenko wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19888/
> -----------------------------------------------------------
> 
> (Updated April 1, 2014, 9:52 p.m.)
> 
> 
> Review request for Aurora, Kevin Sweeney and Bill Farner.
> 
> 
> Bugs: AURORA-261
>     https://issues.apache.org/jira/browse/AURORA-261
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> Before we start storing UNKNOWN (SANDBOX_DELETED) state need to prepare for a graceful
rollback of that change.
> 
> 
> Diffs
> -----
> 
>   src/main/java/org/apache/aurora/scheduler/base/Tasks.java 003d475a1bd4ecc099d9a641fd239a8189f71cdb

>   src/main/java/org/apache/aurora/scheduler/state/TaskStateMachine.java d2becea60e5d7bb59a2e5adb66e10cd50f6b56f3

>   src/test/java/org/apache/aurora/scheduler/state/TaskStateMachineTest.java e77063a9c8e40e015ec264b151a7ed76f1c7f00f

> 
> Diff: https://reviews.apache.org/r/19888/diff/
> 
> 
> Testing
> -------
> 
> gradle clean build
> gradle run
> 
> 
> Thanks,
> 
> Maxim Khutornenko
> 
>


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