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

Reply via email to