Adar Dembo has posted comments on this change. Change subject: docs: workflow for master migration ......................................................................
Patch Set 1: (5 comments) http://gerrit.cloudera.org:8080/#/c/4300/1/docs/administration.adoc 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" Done 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 http://gerrit.cloudera.org:8080/4300 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: I9b9c66505e0efd1f4aef80884346507d4fe08d9c Gerrit-PatchSet: 1 Gerrit-Project: kudu Gerrit-Branch: master Gerrit-Owner: Adar Dembo <a...@cloudera.com> Gerrit-Reviewer: Adar Dembo <a...@cloudera.com> Gerrit-Reviewer: Anonymous Coward #149 Gerrit-Reviewer: David Ribeiro Alves <dral...@apache.org> Gerrit-Reviewer: Kudu Jenkins Gerrit-Reviewer: Todd Lipcon <t...@apache.org> Gerrit-HasComments: Yes
