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


Was thinking about this some more today again.


docs/src/main/asciidoc/design/ACCUMULO-1454-proposal-01.adoc
<https://reviews.apache.org/r/24855/#comment121624>

    Disabling tablet assignment across the cluster could have unintended 
negative consequences. If a tabletserver dies during a rolling upgrade, the 
tablets its hosting would be unavailable until that server is restarted as a 
part of the rolling upgrade script. For large numbers of tservers, that could 
be an extended outage.
    
    It would be better if we could identify some batch of tabletservers, mark 
all tablets currently hosted on those tablet servers as "disabled", and prevent 
any migrations to those servers. This would allow the rest of the cluster to 
continue to operate as normal, while avoiding reassignment churn on the nodes 
being restarted.
    
    It would be more difficult to implement in the master than simply disabling 
assingment completely. We might be able to do it fairly easily with a new value 
in TabletGoalState, but that's only after a very naive look at the code 
recently.



docs/src/main/asciidoc/design/ACCUMULO-1454-proposal-01.adoc
<https://reviews.apache.org/r/24855/#comment121623>

    I have no idea how it was done, but I found myself lamenting that we 
couldn't somehow let the master restart a tabletserver instead of just shutting 
it down.
    
    That would alleviate the shell-scripting burden, but I can't think of a way 
to actually make that happen. I'm going to look at what HBase has for their 
scripting of RU.



docs/src/main/asciidoc/design/ACCUMULO-1454-proposal-01.adoc
<https://reviews.apache.org/r/24855/#comment121622>

    Maybe it would be better to create an Enum for "assignment state". The 
first two values in this enum would be "DISABLE", "ENABLE". This would give us 
some more flexibility in supporting additional states in the future, although I 
can't directly come up with a concrete example.


- Josh Elser


On Aug. 21, 2014, 8:12 p.m., kturner wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24855/
> -----------------------------------------------------------
> 
> (Updated Aug. 21, 2014, 8:12 p.m.)
> 
> 
> Review request for accumulo.
> 
> 
> Bugs: ACCUMULO-1454
>     https://issues.apache.org/jira/browse/ACCUMULO-1454
> 
> 
> Repository: accumulo
> 
> 
> Description
> -------
> 
> Positing ACCUMULO-1454 design doc for review
> 
> 
> Diffs
> -----
> 
>   docs/src/main/asciidoc/design/ACCUMULO-1454-proposal-01.adoc PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/24855/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> kturner
> 
>

Reply via email to