Updating doc in other places to use InitShardMaster.

doc/GettingStartedKubernetes.md

@@ -335,19 +335,21 @@ $ kvtctl RebuildKeyspaceGraph test_keyspace
     so that they start replicating from the master's mysqld.<br><br>
 
     Since this is the first time the shard has been started,
-    the vttablets are not already doing any replication. As a
+    the vttablets are not already doing any replication, and the
+    tablet types are all replica or spare. As a
     result, the following command uses the <code>-force</code>
-    flag when calling the <code>ReparentShard</code> command
-    to skip the usual validation of each tablet's replication state.
+    flag when calling the <code>InitShardMaster</code> command
+    to be able to promote one instance to master.
 
 
     ``` sh
-$ kvtctl ReparentShard -force test_keyspace/0 test-0000000100
+$ kvtctl InitShardMaster -force test_keyspace/0 test-0000000100
 ```
 
     <br>**Note:** If you do not include the <code>-force</code> flag 
-    here, the command will first check to ensure that slave databases
-    are replicating correctly. However, since the slaves aren't
+    here, the command will first check to ensure the provided
+    tablet is the only tablet of type master in the shard.
+    However, since none of the slaves are masters, and we're not
     replicating at all, that check would fail and the command
     would fail as well.<br><br>
 

doc/HorizontalReshardingGuide.md

@@ -21,11 +21,11 @@ Once we have a column that we can use as the sharding key, we need to tell Vites
 
 Create destination shards and tablets just like the source shard was created. For example, you might have `test_keyspace/-80` and `test_keyspace/80-`, if you were splitting the original shard into two shards.
 
-You will need to make sure that each destination shard has a master tablet, and at least one (but preferably two) rdonly tablets. It is necessary to reparent each destination shard, after creating the master tablet, to choose a master. This can be done by, for example:
+You will need to make sure that each destination shard has a master tablet, and at least one (but preferably two) rdonly tablets. It is necessary to initialize the MySQL replication in each destination shard, after creating the master tablet, to choose a master. This can be done by, for example:
 
 ```
-vtctl ReparentShard -force test_keyspace/-80 <master tablet alias>
-vtctl ReparentShard -force test_keyspace/80- <master tablet alias>
+vtctl InitShardMaster -force test_keyspace/-80 <master tablet alias>
+vtctl InitShardMaster -force test_keyspace/80- <master tablet alias>
 ```
 
 At this point, the destination shards should be created, but do not have any data, and will not be serving any traffic.

examples/kubernetes/README.md

@@ -166,11 +166,12 @@ When we pick a master vttablet, Vitess will also take care of connecting the
 other replicas' mysqld instances to start replicating from the master mysqld.
 
 Since this is the first time we're starting up the shards, there is no existing
-replication happening, so we use the -force flag on ReparentShard to skip the
-usual validation of each tablet's replication state.
+replication happening, and all tablets are of the same base replica or spare
+type. So we use the -force flag on InitShardMaster to allow the transition
+of the first tablet from its type to master.
 
 ```
-$ kvtctl ReparentShard -force test_keyspace/0 test-0000000100
+$ kvtctl InitShardMaster -force test_keyspace/0 test-0000000100
 ```
 
 Once this is done, you should see one master and two replicas in vtctld's

examples/kubernetes/cluster-up.sh

@@ -175,7 +175,7 @@ echo Done
 echo -n Reparenting...
 shard_num=1
 for shard in $(echo $SHARDS | tr "," " "); do
-  $kvtctl ReparentShard -force test_keyspace/$shard test-0000000${shard_num}00
+  $kvtctl InitShardMaster -force test_keyspace/$shard test-0000000${shard_num}00
   let shard_num=shard_num+1
 done
 echo Done