Orchestrator upstream moved to github

config/init_db.sql

@@ -63,7 +63,7 @@ GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, FILE,
   SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER
   ON *.* TO 'vt_filtered'@'localhost';
 
-# User for Orchestrator (https://github.com/outbrain/orchestrator).
+# User for Orchestrator (https://github.com/github/orchestrator).
 GRANT SUPER, PROCESS, REPLICATION SLAVE, RELOAD
   ON *.* TO 'orc_client_user'@'%' IDENTIFIED BY 'orc_client_user_password';
 GRANT SELECT

doc/ScalingMySQL.md

@@ -52,7 +52,7 @@ Setting up these components directly -- for example, writing your own topology s
 
 **Optional functionality to implement**
 
-* *Recommended*.  Vitess has basic support for identifying or changing a master, but it doesn't aim to fully address this feature. As such, we recommend using another program, like [Orchestrator](https://github.com/outbrain/orchestrator), to monitor the health of your servers and to change your master database when necessary. (In a sharded database, each shard has a master.)
+* *Recommended*.  Vitess has basic support for identifying or changing a master, but it doesn't aim to fully address this feature. As such, we recommend using another program, like [Orchestrator](https://github.com/github/orchestrator), to monitor the health of your servers and to change your master database when necessary. (In a sharded database, each shard has a master.)
 
 
 * *Recommended*. You should have a way to monitor your database topology and set up alerts as needed. Vitess components facilitate this monitoring by exporting a lot of runtime variables, like QPS over the last few minutes, error rates, and query latency. The variables are exported in JSON format, and Vitess also supports an InfluxDB plug-in.

doc/ServerConfiguration.md

@@ -567,14 +567,14 @@ You will need to run some cron jobs to archive or purge log files periodically.
 
 ### Orchestrator
 
-[Orchestrator](https://github.com/outbrain/orchestrator) is a tool for
+[Orchestrator](https://github.com/github/orchestrator) is a tool for
 managing MySQL replication topologies, including automated failover.
 It can detect master failure and initiate a recovery in a matter of seconds.
 
 For the most part, Vitess is agnostic to the actions of Orchestrator,
 which operates below Vitess at the MySQL level. That means you can
 pretty much
-[set up Orchestrator](https://github.com/outbrain/orchestrator/wiki/Orchestrator-Manual)
+[set up Orchestrator](https://github.com/github/orchestrator/wiki/Orchestrator-Manual)
 in the normal way, with just a few additions as described below.
 
 For the [Kubernetes example](/getting-started/), we provide a

doc/Troubleshooting.md

@@ -41,7 +41,7 @@ writes will fail since they'll be routed to a read-only replica
 (the old master). Use the [TabletExternallyReparented](/reference/vtctl.html#tabletexternallyreparented)
 command to tell Vitess the new master tablet for a shard.
 
-Tools like [Orchestrator](https://github.com/outbrain/orchestrator)
+Tools like [Orchestrator](https://github.com/github/orchestrator)
 can be configured to call this automatically when a failover occurs.
 See our sample [orchestrator.conf.json](https://github.com/youtube/vitess/blob/1129d69282bb738c94b8af661b984b6377a759f7/docker/orchestrator/orchestrator.conf.json#L131)
 for an example of this.

doc/VitessReplication.md

@@ -185,7 +185,7 @@ These behaviors combine to give you the property that, in case of master
 failure, there is at least one other *replica* type slave that has every
 transaction that was ever reported to clients as having completed.
 You can then ([manually](http://vitess.io/reference/vtctl.html#emergencyreparentshard),
-or with an automated tool like [Orchestrator](https://github.com/outbrain/orchestrator))
+or with an automated tool like [Orchestrator](https://github.com/github/orchestrator))
 pick the replica that is farthest ahead in GTID position and promote that to be
 the new master.
 

docs/overview/scaling-mysql.html

@@ -366,7 +366,7 @@
 <p><strong>Optional functionality to implement</strong></p>
 
 <ul>
-<li><p><em>Recommended</em>.  Vitess has basic support for identifying or changing a master, but it doesn&#39;t aim to fully address this feature. As such, we recommend using another program, like <a href="https://github.com/outbrain/orchestrator">Orchestrator</a>, to monitor the health of your servers and to change your master database when necessary. (In a sharded database, each shard has a master.)</p></li>
+<li><p><em>Recommended</em>.  Vitess has basic support for identifying or changing a master, but it doesn&#39;t aim to fully address this feature. As such, we recommend using another program, like <a href="https://github.com/github/orchestrator">Orchestrator</a>, to monitor the health of your servers and to change your master database when necessary. (In a sharded database, each shard has a master.)</p></li>
 <li><p><em>Recommended</em>. You should have a way to monitor your database topology and set up alerts as needed. Vitess components facilitate this monitoring by exporting a lot of runtime variables, like QPS over the last few minutes, error rates, and query latency. The variables are exported in JSON format, and Vitess also supports an InfluxDB plug-in.</p></li>
 <li><p><em>Optional</em>. Using the Kubernetes scripts as a base, you could run Vitess components with other configuration management systems (like Puppet) or frameworks (like Mesos or AWS images).</p></li>
 </ul>

docs/user-guide/server-configuration.html

@@ -905,14 +905,14 @@ needs to point at each cell instance.</li>
 
 <h3 id="orchestrator">Orchestrator</h3>
 
-<p><a href="https://github.com/outbrain/orchestrator">Orchestrator</a> is a tool for
+<p><a href="https://github.com/github/orchestrator">Orchestrator</a> is a tool for
 managing MySQL replication topologies, including automated failover.
 It can detect master failure and initiate a recovery in a matter of seconds.</p>
 
 <p>For the most part, Vitess is agnostic to the actions of Orchestrator,
 which operates below Vitess at the MySQL level. That means you can
 pretty much
-<a href="https://github.com/outbrain/orchestrator/wiki/Orchestrator-Manual">set up Orchestrator</a>
+<a href="https://github.com/github/orchestrator/wiki/Orchestrator-Manual">set up Orchestrator</a>
 in the normal way, with just a few additions as described below.</p>
 
 <p>For the <a href="/getting-started/">Kubernetes example</a>, we provide a

docs/user-guide/troubleshooting.html

@@ -353,7 +353,7 @@ writes will fail since they'll be routed to a read-only replica
 (the old master). Use the <a href="/reference/vtctl.html#tabletexternallyreparented">TabletExternallyReparented</a>
 command to tell Vitess the new master tablet for a shard.</p>
 
-<p>Tools like <a href="https://github.com/outbrain/orchestrator">Orchestrator</a>
+<p>Tools like <a href="https://github.com/github/orchestrator">Orchestrator</a>
 can be configured to call this automatically when a failover occurs.
 See our sample <a href="https://github.com/youtube/vitess/blob/1129d69282bb738c94b8af661b984b6377a759f7/docker/orchestrator/orchestrator.conf.json#L131">orchestrator.conf.json</a>
 for an example of this.</p>

docs/user-guide/vitess-replication.html

@@ -498,7 +498,7 @@ none of replica slaves have).</p></li>
 failure, there is at least one other <em>replica</em> type slave that has every
 transaction that was ever reported to clients as having completed.
 You can then (<a href="http://vitess.io/reference/vtctl.html#emergencyreparentshard">manually</a>,
-or with an automated tool like <a href="https://github.com/outbrain/orchestrator">Orchestrator</a>)
+or with an automated tool like <a href="https://github.com/github/orchestrator">Orchestrator</a>)
 pick the replica that is farthest ahead in GTID position and promote that to be
 the new master.</p>
 

go/vt/mysqlctl/metadata_tables.go

@@ -42,7 +42,7 @@ const sqlCreateShardMetadataTable = `CREATE TABLE IF NOT EXISTS _vt.shard_metada
 // a per-tablet table that is never replicated. This allows queries
 // against local_metadata to return different values on different tablets,
 // which is used for communicating between Vitess and MySQL-level tools like
-// Orchestrator (http://github.com/outbrain/orchestrator).
+// Orchestrator (http://github.com/github/orchestrator).
 // _vt.shard_metadata is a replicated table with per-shard information, but it's
 // created here to make it easier to create it on databases that were running
 // old version of Vitess, or databases that are getting converted to run under