Adar Dembo has posted comments on this change.

Change subject: docs: workflow for master migration

Patch Set 1:

File docs/administration.adoc:

Line 202: For true high availability and to avoid a single point of failure, 
Kudu clusters should be created
> remove "true"

Line 236:   recovering from permanent master failures greatly, and is highly 
recommended. The alias should be
> how? are you linking this to somewhere else, or are you adding this info on
To clarify, is your question "how does it simplify recovering from permanent 
master failures"? Or "how do I configure a DNS cname or /etc/hosts alias"?

To the first question: originally I had an explanation embedded in this 
section, but I found it to be too complex and distracting from the rest of the 
workflow, so I removed it. The actual explanation can be found in the "handling 
permanent failure in masters" design doc, but I don't think it makes sense to 
link to a design doc from product documentation.

To the second question: configuring DNS is out of scope of this document 
because we expect administrators to know how to do that already, or to find 
someone in their organization who does.

Line 244: * Identify and record the directory where the master's data will live.
> this is confusing, the user can "choose" these now since it's running new d
I wanted "record" in there to make it clear that the choice being made needs to 
be remembered for later on.

After that, "choose" and "identify" seem synonymous enough to me, and I think 
it's good to evoke symmetry with respect to the previous step (where we 
identified and recorded the data directory of the existing master).

Line 282: ** `port` is the master's previously recorded RPC port number
> it would be good to have examples for an actual correct command, maybe some
I've added an example for each command.

Line 314: are working properly, consider performing the following sanity checks:
> how does this validate that the new masters are working properly? if the us
Obviously there are a lot of ways that this workflow could be botched. But, if 
the user at least rewrote the Raft configuration on the existing master such 
that it includes multiple entries, a scan will fail if there aren't healthy 
masters behind those entries (because the client will look for a leader master 
and won't find one, since the one working master can't get a majority of votes).

What would you propose as a better means of post-migration validation?

To view, visit
To unsubscribe, visit

Gerrit-MessageType: comment
Gerrit-Change-Id: I9b9c66505e0efd1f4aef80884346507d4fe08d9c
Gerrit-PatchSet: 1
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-Owner: Adar Dembo <>
Gerrit-Reviewer: Adar Dembo <>
Gerrit-Reviewer: Anonymous Coward #149
Gerrit-Reviewer: David Ribeiro Alves <>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Todd Lipcon <>
Gerrit-HasComments: Yes

Reply via email to