From 0ef9fdc2c6c4a993b5d45c32d9c33fb40f4295b5 Mon Sep 17 00:00:00 2001 From: Alain Jobart Date: Mon, 5 Mar 2018 07:31:55 -0800 Subject: [PATCH] Mass-replace youtube/vitess -> vitessio/vitess. Signed-off-by: Alain Jobart --- CONTRIBUTING.md | 2 +- GOVERNANCE.md | 10 +++--- GUIDING_PRINCIPLES.md | 2 +- README.md | 2 +- doc/AdvancedFeaturesIndex.md | 2 +- doc/BackupAndRestore.md | 2 +- doc/CodeReviews.md | 2 +- doc/DockerBuild.md | 10 +++--- doc/GettingStarted.md | 8 ++--- doc/GettingStartedKubernetes.md | 6 ++-- doc/GitHubWorkflow.md | 14 ++++---- doc/LifeOfAQuery.md | 10 +++--- doc/Monitoring.md | 4 +-- doc/Production.md | 2 +- ...icatoinLagBasedThrottlingOfTransactions.md | 4 +-- doc/ScalabilityPhilosophy.md | 4 +-- doc/ScalingMySQL.md | 2 +- doc/ServerConfiguration.md | 14 ++++---- doc/Sharding.md | 2 +- doc/ShardingKubernetes.md | 2 +- doc/TopologyService.md | 2 +- doc/Troubleshooting.md | 2 +- doc/TwoPhaseCommitDesign.md | 4 +-- doc/UpdateStream.md | 2 +- doc/V3HighLevelDesign.md | 6 ++-- doc/VSchema.md | 4 +-- doc/VTGateV3Features.md | 2 +- doc/VindexAsTable.md | 4 +-- doc/Vision.md | 2 +- doc/VitessOverview.md | 2 +- doc/VitessQueues.md | 2 +- doc/VitessTransportSecurityModel.md | 2 +- doc/internal/PublishWebsite.md | 28 +++++++-------- doc/internal/ReleaseInstructions.md | 14 ++++---- doc/vtctlReference.md | 2 +- docker/README.md | 10 +++--- docker/bootstrap/README.md | 2 +- docker/k8s/Dockerfile | 2 +- docker/k8s/vttablet/Dockerfile | 2 +- go/vt/mysqlctl/mycnf_gen.go | 2 +- go/vt/vitessdriver/doc.go | 8 ++--- go/vt/vtctl/vtctl.go | 2 +- go/vt/vtgate/vindexes/lookup_internal.go | 2 +- helm/vitess/Chart.yaml | 2 +- .../src/main/java/io/vitess/client/Proto.java | 2 +- .../main/java/io/vitess/client/RpcClient.java | 34 +++++++++---------- .../java/io/vitess/client/VTGateConn.java | 2 +- .../src/main/java/io/vitess/hadoop/README.md | 6 ++-- java/pom.xml | 10 +++--- test/cluster/keytar/config/vitess_config.yaml | 2 +- test/cluster/keytar/keytar_test.py | 14 ++++---- test/cluster/keytar/test_config.yaml | 2 +- test/legacy_resharding.py | 8 ++--- test/resharding.py | 6 ++-- test/schema.py | 8 ++--- travis/install_grpc.sh | 2 +- 56 files changed, 155 insertions(+), 155 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 62ea1ec90e4..91be041af9a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -25,7 +25,7 @@ the one above, the For all contributors, we recommend the standard [GitHub flow](https://guides.github.com/introduction/flow/) based on [forking and pull requests](https://guides.github.com/activities/forking/). -For significant changes, please [create an issue](https://github.com/youtube/vitess/issues) +For significant changes, please [create an issue](https://github.com/vitessio/vitess/issues) to let everyone know what you're planning to work on, and to track progress and design decisions. ## Guidance for Novice Vitess Developers diff --git a/GOVERNANCE.md b/GOVERNANCE.md index b2d8e5a3d1e..1a8db8bb2fd 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -21,7 +21,7 @@ Users who continue to engage with the project and its community will often becom ## Contributors -Contributors will be added to the [Collaborators list](https://github.com/youtube/vitess/settings/collaboration). +Contributors will be added to the [Collaborators list](https://github.com/vitessio/vitess/settings/collaboration). Contributors are community members who contribute in concrete ways to the project. Anyone can become a contributor. There is no expectation of commitment to the project, no specific skill requirements and no selection process. @@ -42,7 +42,7 @@ Contributors engage with the project through the issue tracker, mailing list, th As contributors gain experience and familiarity with the project, their profile within, and commitment to, the community will increase. At some stage, they may find themselves being nominated for committership. ## Committers -Committers will be added to the [committers list](https://github.com/orgs/youtube/teams/vitess-committers) and the [pullapprove list](https://github.com/youtube/vitess/blob/master/.pullapprove.yml). +Committers will be added to the [committers list](https://github.com/orgs/youtube/teams/vitess-committers) and the [pullapprove list](https://github.com/vitessio/vitess/blob/master/.pullapprove.yml). Committers are community members who have shown that they are committed to the continued development of the project through ongoing engagement with the community. Committership allows contributors to more easily carry on with their project related activities by giving them direct access to the project’s resources. That is, they can make changes directly to project outputs, without having to submit changes via patches. @@ -60,7 +60,7 @@ New committers can be nominated by any existing committer. Once they have been n Nominees may decline their appointment as a committer. However, this is unusual, as the project does not expect any specific time or resource commitment from its community members. The intention behind the role of committer is to allow people to contribute to the project more easily, not to tie them in to the project in any formal way. -It is important to recognise that commitership is a privilege, not a right. That privilege must be earned and once earned it can be removed by the PMC for conduct inconsistent with the [Guiding Principles](https://github.com/youtube/vitess/blob/master/GUIDING_PRINCIPLES.md) or if they drop below a level of commitment and engagement required to be a Committer, as determined by the PMC. The PMC also reserves the right to remove a person for any other reason inconsistent with the goals of Vitess. +It is important to recognise that commitership is a privilege, not a right. That privilege must be earned and once earned it can be removed by the PMC for conduct inconsistent with the [Guiding Principles](https://github.com/vitessio/vitess/blob/master/GUIDING_PRINCIPLES.md) or if they drop below a level of commitment and engagement required to be a Committer, as determined by the PMC. The PMC also reserves the right to remove a person for any other reason inconsistent with the goals of Vitess. A committer who shows an above-average level of contribution to the project, particularly with respect to its strategic direction and long-term health, may be nominated to become a member of the PMC. This role is described below. @@ -86,7 +86,7 @@ Membership of the PMC is by invitation from the existing PMC members. A nominati The number of PMC members should be limited to 7. This number is chosen to ensure that sufficient points of view are represented, while preserving the efficiency of the decision making process. -The PMC is responsible for maintaining the [Guiding Principles](https://github.com/youtube/vitess/blob/master/GUIDING_PRINCIPLES.md) and the code of conduct. It is also responsible for ensuring that those rules and principles are followed. +The PMC is responsible for maintaining the [Guiding Principles](https://github.com/vitessio/vitess/blob/master/GUIDING_PRINCIPLES.md) and the code of conduct. It is also responsible for ensuring that those rules and principles are followed. ## PMC Chair @@ -109,7 +109,7 @@ The Slack channel list is the most appropriate place for a contributor to ask fo Decisions about the future of the project are made by the PMC. New proposals and ideas can be brought to the PMC’s attention through the Slack channel or by filing an issue. If necessary, the PMC will seek input from others to come to the final decision. -The PMC’s decision is itself governed by the project’s [Guiding Principles](https://github.com/youtube/vitess/blob/master/GUIDING_PRINCIPLES.md), which shall be used to reach consensus. If a consensus cannot be reached, a simple majority voting process will be used to reach resolution. In case of a tie, the PMC chair has the casting vote. +The PMC’s decision is itself governed by the project’s [Guiding Principles](https://github.com/vitessio/vitess/blob/master/GUIDING_PRINCIPLES.md), which shall be used to reach consensus. If a consensus cannot be reached, a simple majority voting process will be used to reach resolution. In case of a tie, the PMC chair has the casting vote. # Credits The contents of this document are based on http://oss-watch.ac.uk/resources/meritocraticgovernancemodel by Ross Gardler and Gabriel Hanganu. diff --git a/GUIDING_PRINCIPLES.md b/GUIDING_PRINCIPLES.md index 34cbc9c7ff0..d8bad4dbecb 100644 --- a/GUIDING_PRINCIPLES.md +++ b/GUIDING_PRINCIPLES.md @@ -24,4 +24,4 @@ Vitess is driven by high technical standards, and these must be maintained. It i * Diversity * Inclusiveness * Openness -* Adherence to the [Code of Conduct](https://github.com/youtube/vitess/blob/master/CODE_OF_CONDUCT.md) +* Adherence to the [Code of Conduct](https://github.com/vitessio/vitess/blob/master/CODE_OF_CONDUCT.md) diff --git a/README.md b/README.md index 4f66169fccc..990ffc4350b 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@ [![Maven Central](https://maven-badges.herokuapp.com/maven-central/io.vitess/vitess-jdbc/badge.svg)](https://maven-badges.herokuapp.com/maven-central/io.vitess/vitess-jdbc) -[![Build Status](https://travis-ci.org/youtube/vitess.svg?branch=master)](https://travis-ci.org/youtube/vitess/builds) +[![Build Status](https://travis-ci.org/vitessio/vitess.svg?branch=master)](https://travis-ci.org/vitessio/vitess/builds) [![codebeat badge](https://codebeat.co/badges/51c9a056-1103-4522-9a9c-dc623821ea87)](https://codebeat.co/projects/github-com-youtube-vitess) [![Go Report Card](https://goreportcard.com/badge/vitess.io/vitess)](https://goreportcard.com/report/vitess.io/vitess) diff --git a/doc/AdvancedFeaturesIndex.md b/doc/AdvancedFeaturesIndex.md index 74c04bc363e..0c202e60393 100644 --- a/doc/AdvancedFeaturesIndex.md +++ b/doc/AdvancedFeaturesIndex.md @@ -9,4 +9,4 @@ Examples for undocumented features: * hot row protection in vttablet * vtgate buffer for lossless failovers * vttablet consolidator (avoids duplicated read queries to MySQL, turned on by default) -* [vtexplain](https://github.com/youtube/vitess/blob/master/doc/VtExplain.md) +* [vtexplain](https://github.com/vitessio/vitess/blob/master/doc/VtExplain.md) diff --git a/doc/BackupAndRestore.md b/doc/BackupAndRestore.md index 5e4676058e1..efc5abad937 100644 --- a/doc/BackupAndRestore.md +++ b/doc/BackupAndRestore.md @@ -8,7 +8,7 @@ Vitess. Vitess uses backups for two purposes: Vitess stores data backups on a Backup Storage service, which is a -[pluggable interface](https://github.com/youtube/vitess/blob/master/go/vt/mysqlctl/backupstorage/interface.go). +[pluggable interface](https://github.com/vitessio/vitess/blob/master/go/vt/mysqlctl/backupstorage/interface.go). Currently, we have plugins for: diff --git a/doc/CodeReviews.md b/doc/CodeReviews.md index 92c0c24c58b..5ffd9130bc3 100644 --- a/doc/CodeReviews.md +++ b/doc/CodeReviews.md @@ -50,7 +50,7 @@ They'll receive an email. During discussions, you can also refer to somebody using the *@username* syntax and they'll receive an email as well. -If you want to receive notifications even when you aren't mentioned, you can go to the [repository page](https://github.com/youtube/vitess) and click *Watch*. +If you want to receive notifications even when you aren't mentioned, you can go to the [repository page](https://github.com/vitessio/vitess) and click *Watch*. ## Approving a Pull Request diff --git a/doc/DockerBuild.md b/doc/DockerBuild.md index 809c29fc909..75ebf150580 100644 --- a/doc/DockerBuild.md +++ b/doc/DockerBuild.md @@ -1,10 +1,10 @@ -By default, the [Kubernetes configs](https://github.com/youtube/vitess/tree/master/examples/kubernetes) +By default, the [Kubernetes configs](https://github.com/vitessio/vitess/tree/master/examples/kubernetes) point to the `vitess/lite` image on [Docker Hub](https://hub.docker.com/u/vitess/). We created the `lite` image as a stripped down version of our main image `base` such that Kubernetes pods can start faster. The `lite` image does not change very often and is updated manually by the Vitess team with every release. In contrast, the `base` image is updated automatically after every push to the GitHub master branch. -For more information on the different images we provide, please read the [`docker/README.md` file](https://github.com/youtube/vitess/tree/master/docker). +For more information on the different images we provide, please read the [`docker/README.md` file](https://github.com/vitessio/vitess/tree/master/docker). If your goal is run the latest Vitess code, the simplest solution is to use the bigger `base` image instead of `lite`. @@ -23,9 +23,9 @@ Then you can run our build script for the `lite` image which extracts the Vitess 1. Go to your `src/vitess.io/vitess` directory. 1. Usually, you won't need to [build your own bootstrap image] - (https://github.com/youtube/vitess/blob/master/docker/bootstrap/README.md) - unless you edit [bootstrap.sh](https://github.com/youtube/vitess/blob/master/bootstrap.sh) - or [vendor.json](https://github.com/youtube/vitess/blob/master/vendor/vendor.json), + (https://github.com/vitessio/vitess/blob/master/docker/bootstrap/README.md) + unless you edit [bootstrap.sh](https://github.com/vitessio/vitess/blob/master/bootstrap.sh) + or [vendor.json](https://github.com/vitessio/vitess/blob/master/vendor/vendor.json), for example to add new dependencies. If you do need it then build the bootstrap image, otherwise pull the image using one of the following commands depending on the MySQL flavor you want: diff --git a/doc/GettingStarted.md b/doc/GettingStarted.md index 82d8c83d6b6..072a2885eed 100644 --- a/doc/GettingStarted.md +++ b/doc/GettingStarted.md @@ -45,9 +45,9 @@ $ docker inspect 32f187ef9351 | grep IPAddress You can also build Vitess Docker images yourself to include your own patches or configuration data. The -[Dockerfile](https://github.com/youtube/vitess/blob/master/Dockerfile) +[Dockerfile](https://github.com/vitessio/vitess/blob/master/Dockerfile) in the root of the Vitess tree builds the `vitess/base` image. -The [docker](https://github.com/youtube/vitess/tree/master/docker) +The [docker](https://github.com/vitessio/vitess/tree/master/docker) subdirectory contains scripts for building other images, such as `vitess/lite`. Our `Makefile` also contains rules to build the images. For example: @@ -236,7 +236,7 @@ In addition, Vitess requires the software and libraries listed below. ``` sh cd $WORKSPACE - git clone https://github.com/youtube/vitess.git \ + git clone https://github.com/vitessio/vitess.git \ src/vitess.io/vitess cd src/vitess.io/vitess ``` @@ -351,7 +351,7 @@ pkill -f '(vtdataroot|VTDATAROOT)' # kill Vitess processes This error often means your disk is too slow. If you don't have access to an SSD, you can try [testing against a -ramdisk](https://github.com/youtube/vitess/blob/master/doc/TestingOnARamDisk.md). +ramdisk](https://github.com/vitessio/vitess/blob/master/doc/TestingOnARamDisk.md). ##### Connection refused to tablet, MySQL socket not found, etc. diff --git a/doc/GettingStartedKubernetes.md b/doc/GettingStartedKubernetes.md index eae1393d630..9b935698f5a 100644 --- a/doc/GettingStartedKubernetes.md +++ b/doc/GettingStartedKubernetes.md @@ -193,7 +193,7 @@ $ export KUBECTL=/example/path/to/google-cloud-sdk/bin/kubectl Direct support for other cloud blob stores like Amazon S3 can be added by implementing the Vitess [BackupStorage plugin interface] - (https://github.com/youtube/vitess/blob/master/go/vt/mysqlctl/backupstorage/interface.go). + (https://github.com/vitessio/vitess/blob/master/go/vt/mysqlctl/backupstorage/interface.go). Let us know on the [discussion forum](https://groups.google.com/forum/#!forum/vitess) if you have any specific plugin requests. @@ -606,7 +606,7 @@ vitess/examples/kubernetes$ ./kvtctl.sh ExecuteFetchAsDba test-0000000100 "SELEC ``` The [GuestBook source code] -(https://github.com/youtube/vitess/tree/master/examples/kubernetes/guestbook) +(https://github.com/vitessio/vitess/tree/master/examples/kubernetes/guestbook) provides more detail about how the app server interacts with Vitess. ## Try Vitess resharding @@ -697,7 +697,7 @@ x509: failed to load system roots and no roots provided It usually means that your Kubernetes nodes are running a host OS that puts root certificates in a different place than our configuration expects by default (for example, Fedora). See the comments in the -[etcd controller template](https://github.com/youtube/vitess/blob/master/examples/kubernetes/etcd-controller-template.yaml) +[etcd controller template](https://github.com/vitessio/vitess/blob/master/examples/kubernetes/etcd-controller-template.yaml) for examples of how to set the right location for your host OS. You'll also need to adjust the same certificate path settings in the `vtctld` and `vttablet` templates. diff --git a/doc/GitHubWorkflow.md b/doc/GitHubWorkflow.md index f1559fec80d..cf5e6f2783d 100644 --- a/doc/GitHubWorkflow.md +++ b/doc/GitHubWorkflow.md @@ -8,7 +8,7 @@ Our GitHub workflow is a so called triangular workflow: *Image Source:* https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows -The Vitess code is hosted on GitHub (https://github.com/youtube/vitess). +The Vitess code is hosted on GitHub (https://github.com/vitessio/vitess). This repository is called *upstream*. You develop and commit your changes in a clone of our upstream repository (shown as *local* in the image above). Then you push your changes to your forked repository (*origin*) and send us a pull request. @@ -28,12 +28,12 @@ origin git@github.com:/vitess.git (push) To help you keep your fork in sync with the main repo, add an `upstream` remote: ``` -$ git remote add upstream git@github.com:youtube/vitess.git +$ git remote add upstream git@github.com:vitessio/vitess.git $ git remote -v origin git@github.com:/vitess.git (fetch) origin git@github.com:/vitess.git (push) -upstream git@github.com:youtube/vitess.git (fetch) -upstream git@github.com:youtube/vitess.git (push) +upstream git@github.com:vitessio/vitess.git (fetch) +upstream git@github.com:vitessio/vitess.git (push) ``` Now to sync your local `master` branch, do this: @@ -47,7 +47,7 @@ Note: In the example output above we prefixed the prompt with `(master)` to stress the fact that the command must be run from the branch `master`. You can omit the `upstream master` from the `git pull` command when you let your -`master` branch always track the main `youtube/vitess` repository. To achieve +`master` branch always track the main `vitessio/vitess` repository. To achieve this, run this command once: ``` @@ -109,10 +109,10 @@ After this change, you can run `git push` without arguments: (new-feature) $ git push ``` -Then go to the [repository page](https://github.com/youtube/vitess) and it +Then go to the [repository page](https://github.com/vitessio/vitess) and it should prompt you to create a Pull Request from a branch you recently pushed. You can also [choose a branch manually] -(https://github.com/youtube/vitess/compare). +(https://github.com/vitessio/vitess/compare). ## Addressing Changes diff --git a/doc/LifeOfAQuery.md b/doc/LifeOfAQuery.md index e346865cb45..d01e0df8dac 100644 --- a/doc/LifeOfAQuery.md +++ b/doc/LifeOfAQuery.md @@ -11,7 +11,7 @@ Life of A Query A query means a request for information from database and it involves four components in the case of Vitess, including the client application, VtGate, VtTablet and MySQL instance. This doc explains the interaction which happens between and within components. -![](https://raw.githubusercontent.com/youtube/vitess/master/doc/life_of_a_query.png) +![](https://raw.githubusercontent.com/vitessio/vitess/master/doc/life_of_a_query.png) At a very high level, as the graph shows, first the client sends a query to VtGate. VtGate then resolves the query and routes it to the right VtTablets. For each VtTablet that receives the query, it does necessary validations and passes the query to the underlying MySQL instance. After gathering results from MySQL, VtTablet sends the response back to VtGate. Once VtGate receives responses from all VtTablets, it sends the combined result to the client. In the presence of VtTablet errors, VtGate will retry the query if errors are recoverable and it only fails the query if either errors are unrecoverable or the maximum number of retries has been reached. @@ -19,13 +19,13 @@ At a very high level, as the graph shows, first the client sends a query to VtGa A client application first sends an rpc with an embedded sql query to VtGate. VtGate's rpc server unmarshals this rpc request, calls the appropriate VtGate method and return its result back to client. -![](https://raw.githubusercontent.com/youtube/vitess/master/doc/life_of_a_query_client_to_vtgate.png) +![](https://raw.githubusercontent.com/vitessio/vitess/master/doc/life_of_a_query_client_to_vtgate.png) VtGate keeps an in-memory table that stores all available rpc methods for each service, e.g. VtGate uses "VTGate" as its service name and most of its methods defined in [go/vt/vtgate/vtgate.go](../go/vt/vtgate/vtgate.go) are used to serve rpc request. ## From VtGate to VtTablet -![](https://raw.githubusercontent.com/youtube/vitess/master/doc/life_of_a_query_vtgate_to_vttablet.png) +![](https://raw.githubusercontent.com/vitessio/vitess/master/doc/life_of_a_query_vtgate_to_vttablet.png) After receiving an rpc call from the client and one of its Execute* method being invoked, VtGate needs to figure out which shards should receive the query and send it to each of them. In addition, VtGate talks to the topo server to get necessary information to create a VtTablet connection for each shard. At this point, VtGate is able to send the query to the right VtTablets in parallel. VtGate also does retry if timeout happens or some VtTablets return recoverable errors. @@ -35,13 +35,13 @@ A ShardConn object represents a load balanced connection to a group of VtTablets ## From VtTablet to MySQL -![](https://raw.githubusercontent.com/youtube/vitess/master/doc/life_of_a_query_vttablet_to_mysql.png) +![](https://raw.githubusercontent.com/vitessio/vitess/master/doc/life_of_a_query_vttablet_to_mysql.png) Once VtTablet received an rpc call from VtGate, it does a few checks before passing the query to MySQL. First, it validates the current VtTablet state including the session id, then generates a query plan and applies predefined query rules and does ACL checks. It also checks whether the query hits the row cache and returns the result immediately if so. In addition, VtTablet consolidates duplicate queries from executing simultaneously and shares results between them. At this point, VtTablet has no way but pass the query down to MySQL layer and wait for the result. ## Putting it all together -![](https://raw.githubusercontent.com/youtube/vitess/master/doc/life_of_a_query_all.png) +![](https://raw.githubusercontent.com/vitessio/vitess/master/doc/life_of_a_query_all.png) ## TopoServer diff --git a/doc/Monitoring.md b/doc/Monitoring.md index 3a0b5b6ea28..d6dbc3f4c45 100644 --- a/doc/Monitoring.md +++ b/doc/Monitoring.md @@ -26,9 +26,9 @@ By default, the stats_emit_period is 60s, so each component will push stats to t Vitess has a preliminary plug-in to support InfluxDB as a push-based metrics backend. However, there is very limited support at this time, as InfluxDB itself is going through various API breaking changes. -It should be fairly straightforward to write your own plug-in, if you want to support a different backend. The plug-in package simply needs to implement the `PushBackend` interface of the `stats` package. For an example, you can see the [InfluxDB plugin](https://github.com/youtube/vitess/blob/master/go/stats/influxdbbackend/influxdb_backend.go). +It should be fairly straightforward to write your own plug-in, if you want to support a different backend. The plug-in package simply needs to implement the `PushBackend` interface of the `stats` package. For an example, you can see the [InfluxDB plugin](https://github.com/vitessio/vitess/blob/master/go/stats/influxdbbackend/influxdb_backend.go). -Once you’ve written the backend plug-in, you also need to register the plug-in from within all the relevant Vitess binaries. An example of how to do this can be seen in [this pull request](https://github.com/youtube/vitess/pull/469). +Once you’ve written the backend plug-in, you also need to register the plug-in from within all the relevant Vitess binaries. An example of how to do this can be seen in [this pull request](https://github.com/vitessio/vitess/pull/469). You can then specify that Vitess should publish stats to the backend that you’re targeting by using the `--stats_backend` flag. diff --git a/doc/Production.md b/doc/Production.md index 625a3680792..1b49fca93b9 100644 --- a/doc/Production.md +++ b/doc/Production.md @@ -30,5 +30,5 @@ See the [Getting Started]({% link getting-started/index.md %}) guide. ## Deploying on bare metal See the -[Local Setup](https://github.com/youtube/vitess/tree/master/examples/local) +[Local Setup](https://github.com/vitessio/vitess/tree/master/examples/local) scripts for examples of how to bring up a Vitess cluster manually. diff --git a/doc/ReplicatoinLagBasedThrottlingOfTransactions.md b/doc/ReplicatoinLagBasedThrottlingOfTransactions.md index ee70279d877..97d8500876f 100644 --- a/doc/ReplicatoinLagBasedThrottlingOfTransactions.md +++ b/doc/ReplicatoinLagBasedThrottlingOfTransactions.md @@ -21,11 +21,11 @@ A boolean flag controling whether the replication-lag-based throttling is enable * *tx-throttler-config* -A text-format representation of the [throttlerdata.Configuration](https://github.com/youtube/vitess/blob/master/proto/throttlerdata.proto) protocol buffer +A text-format representation of the [throttlerdata.Configuration](https://github.com/vitessio/vitess/blob/master/proto/throttlerdata.proto) protocol buffer that contains configuration options for the throttler. The most important fields in that message are *target_replication_lag_sec* and *max_replication_lag_sec* that specify the desired limits on the replication lag. See the comments in the protocol definition file for more details. -If this is not specified a [default](https://github.com/youtube/vitess/blob/master/go/vt/tabletserver/tabletenv/config.go) configuration will be used. +If this is not specified a [default](https://github.com/vitessio/vitess/blob/master/go/vt/tabletserver/tabletenv/config.go) configuration will be used. * *tx-throttler-healthcheck-cells* diff --git a/doc/ScalabilityPhilosophy.md b/doc/ScalabilityPhilosophy.md index 2e1838fd7d6..f709a416e48 100644 --- a/doc/ScalabilityPhilosophy.md +++ b/doc/ScalabilityPhilosophy.md @@ -91,7 +91,7 @@ traffic. Vitess supports MapReduce access to the data. Vitess provides a Hadoop connector, that can also be used with Apache Spark. See the [Hadoop package -documentation](https://github.com/youtube/vitess/tree/master/java/hadoop/src/main/java/io/vitess/hadoop) +documentation](https://github.com/vitessio/vitess/tree/master/java/hadoop/src/main/java/io/vitess/hadoop) for more information. With a MapReduce framework, Vitess does not support very complicated @@ -201,7 +201,7 @@ A few things to consider: * *vtcombo* can also start the *vtctld* component, so the test environment is visible with the Vitess UI. * See - [vttest.proto](https://github.com/youtube/vitess/blob/master/proto/vttest.proto) + [vttest.proto](https://github.com/vitessio/vitess/blob/master/proto/vttest.proto) for more information. ## Application query patterns diff --git a/doc/ScalingMySQL.md b/doc/ScalingMySQL.md index b8f87c48d31..16139991c2a 100644 --- a/doc/ScalingMySQL.md +++ b/doc/ScalingMySQL.md @@ -43,7 +43,7 @@ Vitess has several components that keep this complexity out of your application: * The **vtctl** and **vtctld** tools offer command-line and web interfaces to the system.
-Diagram showing Vitess implementation +Diagram showing Vitess implementation
diff --git a/doc/ServerConfiguration.md b/doc/ServerConfiguration.md index 37e46415cb0..7cd2449bf2d 100644 --- a/doc/ServerConfiguration.md +++ b/doc/ServerConfiguration.md @@ -13,13 +13,13 @@ MySQL versions supported are: MariaDB 10.0, MySQL 5.6 and MySQL 5.7. A number of #### my.cnf The main `my.cnf` file is generated by -[mysqlctl init](https://github.com/youtube/vitess/blob/312064b96ac0070d9f8990e57af6f2c0a76a45a9/examples/local/vttablet-up.sh#L66) +[mysqlctl init](https://github.com/vitessio/vitess/blob/312064b96ac0070d9f8990e57af6f2c0a76a45a9/examples/local/vttablet-up.sh#L66) based primarily on -[$VTROOT/config/mycnf/default.cnf](https://github.com/youtube/vitess/blob/master/config/mycnf/default.cnf). +[$VTROOT/config/mycnf/default.cnf](https://github.com/vitessio/vitess/blob/master/config/mycnf/default.cnf). Additional files will be appended to the generated `my.cnf` as specified in a colon-separated list of absolute paths in the `EXTRA_MY_CNF` environment variable. For example, this is typically used to include [flavor-specific -config files](https://github.com/youtube/vitess/blob/312064b96ac0070d9f8990e57af6f2c0a76a45a9/examples/local/vttablet-up.sh#L41). +config files](https://github.com/vitessio/vitess/blob/312064b96ac0070d9f8990e57af6f2c0a76a45a9/examples/local/vttablet-up.sh#L41). To customize the `my.cnf`, you can either add overrides in an additional `EXTRA_MY_CNF` file, or modify the files in `$VTROOT/config/mycnf` before @@ -32,7 +32,7 @@ rather than baking them into a custom container image. When a new instance is initialized with `mysqlctl init` (as opposed to restarting in a previously initialized data dir with `mysqlctl start`), -the [init_db.sql](https://github.com/youtube/vitess/blob/master/config/init_db.sql) +the [init_db.sql](https://github.com/vitessio/vitess/blob/master/config/init_db.sql) file is applied to the server immediately after executing `mysql_install_db`. By default, this file contains the equivalent of running [mysql_secure_installation](https://dev.mysql.com/doc/refman/5.7/en/mysql-secure-installation.html), @@ -495,7 +495,7 @@ This URL prints out a simple "ok" or “not ok” string that can be used to che #### /querylogz, /debug/querylog, /txlogz, /debug/txlog -* /debug/querylog is a never-ending stream of currently executing queries with verbose information about each query. This URL can generate a lot of data because it streams every query processed by VTTablet. The details are as per this function: [https://github.com/youtube/vitess/blob/master/go/vt/tabletserver/logstats.go#L202](https://github.com/youtube/vitess/blob/master/go/vt/tabletserver/logstats.go#L202) +* /debug/querylog is a never-ending stream of currently executing queries with verbose information about each query. This URL can generate a lot of data because it streams every query processed by VTTablet. The details are as per this function: [https://github.com/vitessio/vitess/blob/master/go/vt/tabletserver/logstats.go#L202](https://github.com/vitessio/vitess/blob/master/go/vt/tabletserver/logstats.go#L202) * /querylogz is a limited human readable version of /debug/querylog. It prints the next 300 queries by default. The limit can be specified with a limit=N parameter on the URL. * /txlogz is like /querylogz, but for transactions. * /debug/txlog is the JSON counterpart to /txlogz. @@ -616,7 +616,7 @@ pretty much in the normal way, with just a few additions as described below. For the [Kubernetes example](/getting-started/), we provide a -[sample script](https://github.com/youtube/vitess/blob/master/examples/kubernetes/orchestrator-up.sh) +[sample script](https://github.com/vitessio/vitess/blob/master/examples/kubernetes/orchestrator-up.sh) to launch Orchestrator for you with these settings applied. #### Orchestrator configuration @@ -627,7 +627,7 @@ like the tablet aliases and whether semisync is enforced We pass this information by telling Orchestrator to execute certain queries that return local metadata from a non-replicated table, as seen in our sample -[orchestrator.conf.json](https://github.com/youtube/vitess/blob/master/docker/orchestrator/orchestrator.conf.json): +[orchestrator.conf.json](https://github.com/vitessio/vitess/blob/master/docker/orchestrator/orchestrator.conf.json): ```json "DetectClusterAliasQuery": "SELECT value FROM _vt.local_metadata WHERE name='ClusterAlias'", diff --git a/doc/Sharding.md b/doc/Sharding.md index edf8fc081b4..e50ff737d4f 100644 --- a/doc/Sharding.md +++ b/doc/Sharding.md @@ -182,6 +182,6 @@ Vitess provides the following tools to help manage range-based shards: * The [vtctl]({% link reference/vtctl.md %}) command-line tool supports functions for managing keyspaces, shards, tablets, and more. * Client APIs account for sharding operations. -* The [MapReduce framework](https://github.com/youtube/vitess/tree/master/java/hadoop/src/main/java/io/vitess/hadoop) +* The [MapReduce framework](https://github.com/vitessio/vitess/tree/master/java/hadoop/src/main/java/io/vitess/hadoop) fully utilizes key ranges to read data as quickly as possible, concurrently from all shards and all replicas. diff --git a/doc/ShardingKubernetes.md b/doc/ShardingKubernetes.md index b9a6f41cd72..3a6314c93a8 100644 --- a/doc/ShardingKubernetes.md +++ b/doc/ShardingKubernetes.md @@ -17,7 +17,7 @@ the example Vitess cluster in Kubernetes. Since Vitess makes [sharding]({% link user-guide/sharding.md %}) transparent to the app layer, the -[Guestbook](https://github.com/youtube/vitess/tree/master/examples/kubernetes/guestbook) +[Guestbook](https://github.com/vitessio/vitess/tree/master/examples/kubernetes/guestbook) sample app will stay live throughout the [resharding]({% link user-guide/sharding.md %}#resharding) process, confirming that the Vitess cluster continues to serve without downtime. diff --git a/doc/TopologyService.md b/doc/TopologyService.md index 44693b3d31b..cb8a222131b 100644 --- a/doc/TopologyService.md +++ b/doc/TopologyService.md @@ -101,7 +101,7 @@ jobs don’t concurrently alter the data. ### VSchema data The VSchema data contains sharding and routing information for -the [VTGate V3](https://github.com/youtube/vitess/blob/master/doc/VTGateV3Features.md) API. +the [VTGate V3](https://github.com/vitessio/vitess/blob/master/doc/VTGateV3Features.md) API. ## Local data diff --git a/doc/Troubleshooting.md b/doc/Troubleshooting.md index f418d5724bb..2937e405658 100644 --- a/doc/Troubleshooting.md +++ b/doc/Troubleshooting.md @@ -43,5 +43,5 @@ command to tell Vitess the new master tablet for a shard. 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) +See our sample [orchestrator.conf.json](https://github.com/vitessio/vitess/blob/1129d69282bb738c94b8af661b984b6377a759f7/docker/orchestrator/orchestrator.conf.json#L131) for an example of this. diff --git a/doc/TwoPhaseCommitDesign.md b/doc/TwoPhaseCommitDesign.md index e3ec345e8d7..312a031f2d7 100644 --- a/doc/TwoPhaseCommitDesign.md +++ b/doc/TwoPhaseCommitDesign.md @@ -106,7 +106,7 @@ For #1 and #2, the Rollback workflow is initiated. For #3, the commit is resumed The following diagram illustrates the life-cycle of a Vitess transaction. -![](https://raw.githubusercontent.com/youtube/vitess/master/doc/TxLifecycle.png) +![](https://raw.githubusercontent.com/vitessio/vitess/master/doc/TxLifecycle.png) A transaction generally starts off as a single DB transaction. It becomes a distributed transaction as soon as more than one VTTablet is affected. If the app issues a rollback, then all participants are simply rolled back. If a BEC is issued, then all transactions are individually committed. These actions are the same irrespective of single or distributed transactions. @@ -132,7 +132,7 @@ In order to make 2PC work, the following pieces of functionality have to be buil The diagram below show how the various components interact. -![](https://raw.githubusercontent.com/youtube/vitess/master/doc/TxInteractions.png) +![](https://raw.githubusercontent.com/vitessio/vitess/master/doc/TxInteractions.png) The detailed design explains all the functionalities and interactions. diff --git a/doc/UpdateStream.md b/doc/UpdateStream.md index b90d03c75fe..8891fb11cd9 100644 --- a/doc/UpdateStream.md +++ b/doc/UpdateStream.md @@ -415,7 +415,7 @@ A regular appserver will query the cache for the value it wants. It will get eit To see a sample use of the Update Stream feature, look at the -[cache_invalidation.py](https://github.com/youtube/vitess/blob/master/test/cache_invalidation.py) integration +[cache_invalidation.py](https://github.com/vitessio/vitess/blob/master/test/cache_invalidation.py) integration test. It shows how to do the invalidaiton in python, and the application component. diff --git a/doc/V3HighLevelDesign.md b/doc/V3HighLevelDesign.md index 53337394fac..ebbd647fff7 100644 --- a/doc/V3HighLevelDesign.md +++ b/doc/V3HighLevelDesign.md @@ -6,7 +6,7 @@ The goal of this document is to describe the guiding principles that will be use ### Prerequisites -Before reading this doc you must be familiar with [vindexes](https://github.com/youtube/vitess/blob/master/doc/V3VindexDesign.md), which is used as foundation for the arguments presented here. +Before reading this doc you must be familiar with [vindexes](https://github.com/vitessio/vitess/blob/master/doc/V3VindexDesign.md), which is used as foundation for the arguments presented here. # Background @@ -782,7 +782,7 @@ Recapitulating what we’ve covered so far: Once we start allowing joins and subqueries, we have a whole bunch of table aliases and relationships to deal with. We have to contend with name clashes, self-joins, as well as scoping rules. In a way, the vschema has acted as a static symbol table so far. But that’s not going to be enough any more. -The core of the symbol table will contain a map whose key will be a table alias, and the elements will be [similar to the table in vschema](https://github.com/youtube/vitess/blob/master/go/vt/vtgate/planbuilder/schema.go#L22). However, it will also contain a column list that will be built as the query is parsed. +The core of the symbol table will contain a map whose key will be a table alias, and the elements will be [similar to the table in vschema](https://github.com/vitessio/vitess/blob/master/go/vt/vtgate/planbuilder/schema.go#L22). However, it will also contain a column list that will be built as the query is parsed. ### A simple example @@ -1194,7 +1194,7 @@ The overall strategy is as follows: In order to align ourselves with our priorities, we’ll start off with a limited set of primitives, and then we can expand from there. -VTGate already has `Route` and `RouteMerge` as primitives. To this list, let’s add `Join` and `LeftJoin`. Using these primitives, we should be able to cover priorities 1-3 (mentioned in the [Prioritization](https://github.com/youtube/vitess/blob/sugudoc/doc/V3HighLevelDesign.md#prioritization) section). So, any constructs that will require VTGate to do additional work will not be supported. Here’s a recap of what each primitive must do: +VTGate already has `Route` and `RouteMerge` as primitives. To this list, let’s add `Join` and `LeftJoin`. Using these primitives, we should be able to cover priorities 1-3 (mentioned in the [Prioritization](https://github.com/vitessio/vitess/blob/sugudoc/doc/V3HighLevelDesign.md#prioritization) section). So, any constructs that will require VTGate to do additional work will not be supported. Here’s a recap of what each primitive must do: * `Route`: Sends a query to a single shard or unsharded keyspace. * `RouteMerge`: Sends a (mostly) identical query to multiple shards and returns the combined results in no particular order. diff --git a/doc/VSchema.md b/doc/VSchema.md index 32b05988d73..f06cd6403b4 100644 --- a/doc/VSchema.md +++ b/doc/VSchema.md @@ -103,7 +103,7 @@ Lookup NonUnique | 20 In the case of a simple select, Vitess scans the WHERE clause to match references to Vindex columns and chooses the best one to use. If there is no match and the query is simple without complex constructs like aggreates, etc, it is sent to all shards. -Vitess can handle more complex queries. For now, you can refer to the [design doc](https://github.com/youtube/vitess/blob/master/doc/V3HighLevelDesign.md) on how it handles them. +Vitess can handle more complex queries. For now, you can refer to the [design doc](https://github.com/vitessio/vitess/blob/master/doc/V3HighLevelDesign.md) on how it handles them. #### Insert @@ -149,7 +149,7 @@ If you have multiple unsharded keyspaces, you can still avoid defining a VSchema 1. Connect to a keyspace and all queries are sent to it. 2. Connect to Vitess without specifying a keyspace, but use qualifed names for tables, like `keyspace.table` in your queries. -However, once the setup exceeds the above complexity, VSchemas become a necessity. Vitess has a [working demo](https://github.com/youtube/vitess/tree/master/examples/demo) of VSchemas. This section documents the various features highlighted with snippets pulled from the demo. +However, once the setup exceeds the above complexity, VSchemas become a necessity. Vitess has a [working demo](https://github.com/vitessio/vitess/tree/master/examples/demo) of VSchemas. This section documents the various features highlighted with snippets pulled from the demo. ### Unsharded Table diff --git a/doc/VTGateV3Features.md b/doc/VTGateV3Features.md index 989bccd0e60..60ee600cc19 100644 --- a/doc/VTGateV3Features.md +++ b/doc/VTGateV3Features.md @@ -34,7 +34,7 @@ there are some additional benefits: underneath without changing much of the app. The -[V3 design](https://github.com/youtube/vitess/blob/master/doc/V3VindexDesign.md) +[V3 design](https://github.com/vitessio/vitess/blob/master/doc/V3VindexDesign.md) is quite elaborate. If necessary, it will allow you to plug in custom indexes and sharding schemes. However, it comes equipped with some pre-cooked recipes that satisfy the immediate needs of the real-world: diff --git a/doc/VindexAsTable.md b/doc/VindexAsTable.md index 964f579a106..594b4ea4cde 100644 --- a/doc/VindexAsTable.md +++ b/doc/VindexAsTable.md @@ -1,6 +1,6 @@ # Proposal: Expose Vindexes as Tables -This proposal is in response to issues like [#3076](https://github.com/youtube/vitess/issues/3076). Users want the ability to perform vindex functions independently from the tables they are associated with. +This proposal is in response to issues like [#3076](https://github.com/vitessio/vitess/issues/3076). Users want the ability to perform vindex functions independently from the tables they are associated with. ## Design @@ -10,7 +10,7 @@ One can think of a vindex as a table that looks like this: create my_vdx(id int, keyspace_id varbinary(255)) // id can be of any type. ``` -Looking at the vindex interface defined [here](https://github.com/youtube/vitess/blob/master/go/vt/vtgate/vindexes/vindex.go), we can come up with SQL syntax that represents them: +Looking at the vindex interface defined [here](https://github.com/vitessio/vitess/blob/master/go/vt/vtgate/vindexes/vindex.go), we can come up with SQL syntax that represents them: * Map: `select id, keyspace_id from my_vdx where id = :id`. * Create: `insert into my_vdx values(:id, :keyspace_id)`. * Delete: `delete from my_vdx where id = :id and keyspace_id :keyspace_id`. diff --git a/doc/Vision.md b/doc/Vision.md index f33f5eb0e93..7df33c1d221 100644 --- a/doc/Vision.md +++ b/doc/Vision.md @@ -70,4 +70,4 @@ data is stored only once, and fetched only if needed. The following diagram illustrates where vitess fits in the spectrum of storage solutions: -![Spectrum](https://raw.github.com/youtube/vitess/master/doc/VitessSpectrum.png) +![Spectrum](https://raw.github.com/vitessio/vitess/master/doc/VitessSpectrum.png) diff --git a/doc/VitessOverview.md b/doc/VitessOverview.md index fb0703f158c..9b014b909a1 100644 --- a/doc/VitessOverview.md +++ b/doc/VitessOverview.md @@ -120,7 +120,7 @@ Vitess tools and servers are designed to help you whether you start with a compl The diagram below illustrates Vitess' components:
-Diagram showing Vitess implementation +Diagram showing Vitess implementation
### Topology diff --git a/doc/VitessQueues.md b/doc/VitessQueues.md index eb90b761927..c570fa4ec55 100644 --- a/doc/VitessQueues.md +++ b/doc/VitessQueues.md @@ -79,7 +79,7 @@ capabilities, the usual horizontal sharding process can be used. Queue Tables are marked in the schema by a comment, in a similar way we detect Sequence Tables -[now](https://github.com/youtube/vitess/blob/master/go/vt/tabletserver/table_info.go#L37). +[now](https://github.com/vitessio/vitess/blob/master/go/vt/tabletserver/table_info.go#L37). When a tablet becomes a master, and there are Queue tables, it creates a QueueManager for each of them. diff --git a/doc/VitessTransportSecurityModel.md b/doc/VitessTransportSecurityModel.md index b1fb19d05bb..3e540a9e5d5 100644 --- a/doc/VitessTransportSecurityModel.md +++ b/doc/VitessTransportSecurityModel.md @@ -97,7 +97,7 @@ Therefore, this flag is not enabled by default. ### Example For a concrete example, see -[test/encrypted\_transport.py](https://github.com/youtube/vitess/blob/master/test/encrypted_transport.py) +[test/encrypted\_transport.py](https://github.com/vitessio/vitess/blob/master/test/encrypted_transport.py) in the source tree. It first sets up all the certificates, and some table ACLs, then uses the python client to connect with SSL. It also exercises the grpc\_use\_effective\_callerid flag, by connecting without SSL. diff --git a/doc/internal/PublishWebsite.md b/doc/internal/PublishWebsite.md index 08cee649b32..4d657614fea 100644 --- a/doc/internal/PublishWebsite.md +++ b/doc/internal/PublishWebsite.md @@ -4,11 +4,11 @@ Our website [vitess.io](http://vitess.io) are static HTML pages which are generated by [Jekyll](https://github.com/jekyll/jekyll) from Markdown files -located in the [`doc/`](https://github.com/youtube/vitess/tree/master/doc) +located in the [`doc/`](https://github.com/vitessio/vitess/tree/master/doc) directory. The generated files will be put in the -[`docs/`](https://github.com/youtube/vitess/tree/master/docs) directory (note +[`docs/`](https://github.com/vitessio/vitess/tree/master/docs) directory (note the extra **s**). GitHub serves the website from this directory off the master branch. @@ -45,30 +45,30 @@ branch. We have three main directories: -* [`doc/`](https://github.com/youtube/vitess/tree/master/doc) - original +* [`doc/`](https://github.com/vitessio/vitess/tree/master/doc) - original content -* [`docs/`](https://github.com/youtube/vitess/tree/master/docs) - generated +* [`docs/`](https://github.com/vitessio/vitess/tree/master/docs) - generated website actually served at http://vitess.io/ -* [`vitess.io/`](https://github.com/youtube/vitess/tree/master/vitess.io) - +* [`vitess.io/`](https://github.com/vitessio/vitess/tree/master/vitess.io) - all relevant files for the website e.g. * Jekyll configuration * images e.g. our logo * CSS * [Navigation - menu](https://github.com/youtube/vitess/blob/master/vitess.io/_includes/left-nav-menu.html) + menu](https://github.com/vitessio/vitess/blob/master/vitess.io/_includes/left-nav-menu.html) * boiler plate markdown files which include the actual content from the `doc/` directory - ([example](https://github.com/youtube/vitess/blob/master/vitess.io/contributing/github-workflow.md)) + ([example](https://github.com/vitessio/vitess/blob/master/vitess.io/contributing/github-workflow.md)) The boiler plate markdown files have multiple purposes: * feed the actual content into a template which adds e.g. the navigation to the file * re-arrange paths on the website e.g. - [`doc/GitHubWorkFlow.md`](https://github.com/youtube/vitess/blob/master/doc/GitHubWorkflow.md) + [`doc/GitHubWorkFlow.md`](https://github.com/vitessio/vitess/blob/master/doc/GitHubWorkflow.md) is actually served as http://vitess.io/contributing/github-workflow/ because there is the file - [`vitess.io/contributing/github-workflow.md`](https://github.com/youtube/vitess/blob/master/vitess.io/contributing/github-workflow.md). + [`vitess.io/contributing/github-workflow.md`](https://github.com/vitessio/vitess/blob/master/vitess.io/contributing/github-workflow.md). ### Changing Content @@ -94,9 +94,9 @@ Note that you have to refer to the `.md` file of the page. Example: If you want to add a new page, you must also: * add it to the left menu: - [`vitess.io/_includes/left-nav-menu.html`](https://github.com/youtube/vitess/blob/master/vitess.io/_includes/left-nav-menu.html) + [`vitess.io/_includes/left-nav-menu.html`](https://github.com/vitessio/vitess/blob/master/vitess.io/_includes/left-nav-menu.html) * create a boiler plate .md file. Example: - [`vitess.io/contributing/github-workflow.md`](https://github.com/youtube/vitess/blob/master/vitess.io/contributing/github-workflow.md) + [`vitess.io/contributing/github-workflow.md`](https://github.com/vitessio/vitess/blob/master/vitess.io/contributing/github-workflow.md) When you add a new section to the menu, please create a new directory below `vitess.io/`. For example, the "Contributing" section is served out of @@ -117,8 +117,8 @@ http://vitess.io. Examples: -* https://github.com/youtube/vitess/blob/master/doc/LifeOfAQuery.md -* https://github.com/youtube/vitess/blob/master/doc/V3VindexDesign.md +* https://github.com/vitessio/vitess/blob/master/doc/LifeOfAQuery.md +* https://github.com/vitessio/vitess/blob/master/doc/V3VindexDesign.md This is fine and accepted. Users can still view them on GitHub.com. @@ -126,7 +126,7 @@ Note that these files should include images using the full path e.g. in `LifeOfAQuery.md`: ``` -![](https://raw.githubusercontent.com/youtube/vitess/master/doc/life_of_a_query.png) +![](https://raw.githubusercontent.com/vitessio/vitess/master/doc/life_of_a_query.png) ``` Otherwise GitHub cannot find and show the images. diff --git a/doc/internal/ReleaseInstructions.md b/doc/internal/ReleaseInstructions.md index 16db290882d..f44fa8c2c47 100644 --- a/doc/internal/ReleaseInstructions.md +++ b/doc/internal/ReleaseInstructions.md @@ -1,7 +1,7 @@ # Release Instructions This page describes the steps for cutting a new [open source release] -(https://github.com/youtube/vitess/releases). +(https://github.com/vitessio/vitess/releases). ## Versioning @@ -15,7 +15,7 @@ backward-incompatible way -- for example, when removing deprecated interfaces. Our public API includes (but is not limited to): * The VTGate [RPC interfaces] - (https://github.com/youtube/vitess/tree/master/proto). + (https://github.com/vitessio/vitess/tree/master/proto). * The interfaces exposed by the VTGate client library in each language. Care must also be taken when changing the format of any data stored by a live @@ -45,7 +45,7 @@ precedence. ## Milestones -[GitHub Milestones](https://github.com/youtube/vitess/milestones) are hotlists +[GitHub Milestones](https://github.com/vitessio/vitess/milestones) are hotlists for Issues and Pull Requests. When it's time to start planning a new Vitess release, create a milestone for it @@ -63,7 +63,7 @@ and tag the following items under it: ## Release Branches Each minor release level (X.Y) should have a [release branch] -(https://github.com/youtube/vitess/branches/all?query=release) named +(https://github.com/vitessio/vitess/branches/all?query=release) named `release-X.Y`. This branch should diverge from `master` when the code freeze for that release is declared, after which point only bugfix PRs should be cherrypicked onto the branch. All other activity on `master` will go out with a @@ -241,7 +241,7 @@ At the end of the release, you will also have to bump the SNAPSHOT version in th ## Push the release branch and tag to upstream -Note that we're pushing to upstream (youtube/vitess), not origin (your fork). +Note that we're pushing to upstream (vitessio/vitess), not origin (your fork).

Warning: After the following push, there's no going back, since tags don't get updated if someone else has fetched them already. @@ -257,8 +257,8 @@ git push upstream vX.Y.Z ## Add release notes and send announcement -[Find your new tag](https://github.com/youtube/vitess/tags) and add release -notes. Use the GitHub [Compare](https://github.com/youtube/vitess/compare) tool +[Find your new tag](https://github.com/vitessio/vitess/tags) and add release +notes. Use the GitHub [Compare](https://github.com/vitessio/vitess/compare) tool to see all the commits since the last release. Then send an announcement on the [vitess-announce] diff --git a/doc/vtctlReference.md b/doc/vtctlReference.md index 7329cae16f0..cd2527e1e98 100644 --- a/doc/vtctlReference.md +++ b/doc/vtctlReference.md @@ -1869,7 +1869,7 @@ Deletes the SourceShard record with the provided index. This is meant as an emer ### TabletExternallyReparented -Changes metadata in the topology server to acknowledge a shard master change performed by an external tool. See the Reparenting guide for more information:https://github.com/youtube/vitess/blob/master/doc/Reparenting.md#external-reparents. +Changes metadata in the topology server to acknowledge a shard master change performed by an external tool. See the Reparenting guide for more information:https://github.com/vitessio/vitess/blob/master/doc/Reparenting.md#external-reparents. #### Example diff --git a/docker/README.md b/docker/README.md index 8cb6a3e85f0..1e5edfc923a 100644 --- a/docker/README.md +++ b/docker/README.md @@ -13,7 +13,7 @@ The structure of this directory and our Dockerfile files is guided by the follow * The configuration of each Vitess image is in the directory `docker//`. * Configurations for other images e.g. our internal tool Keytar (see below), can be in a different location. -* Images with more complex build steps have a `build.sh` script e.g. see [lite/build.sh](https://github.com/youtube/vitess/blob/master/docker/lite/build.sh). +* Images with more complex build steps have a `build.sh` script e.g. see [lite/build.sh](https://github.com/vitessio/vitess/blob/master/docker/lite/build.sh). * Tags are used to provide (stable) versions e.g. see tag `v2.0` for the image [vitess/lite](https://hub.docker.com/r/vitess/lite/tags). * Where applicable, we provide a `latest` tag to reference the latest build of an image. @@ -29,7 +29,7 @@ Our list of images can be grouped into: | Image | How (When) Updated | Description | | --- | --- | --- | -| **bootstrap** | manual (after incompatible changes are made to [bootstrap.sh](https://github.com/youtube/vitess/blob/master/bootstrap.sh) or [vendor/vendor.json](https://github.com/youtube/vitess/blob/master/vendor/vendor.json) | Basis for all Vitess images. It is a snapshot of the checked out repository after running `./bootstrap.sh`. Used to cache dependencies. Avoids lengthy recompilation of dependencies if they did not change. Our internal test runner [`test.go`](https://github.com/youtube/vitess/blob/master/test.go) uses it to test the code against different MySQL versions. | +| **bootstrap** | manual (after incompatible changes are made to [bootstrap.sh](https://github.com/vitessio/vitess/blob/master/bootstrap.sh) or [vendor/vendor.json](https://github.com/vitessio/vitess/blob/master/vendor/vendor.json) | Basis for all Vitess images. It is a snapshot of the checked out repository after running `./bootstrap.sh`. Used to cache dependencies. Avoids lengthy recompilation of dependencies if they did not change. Our internal test runner [`test.go`](https://github.com/vitessio/vitess/blob/master/test.go) uses it to test the code against different MySQL versions. | | **base** | automatic (after every GitHub push to the master branch) | Contains all Vitess server binaries. Snapshot after running `make build`. | | **root** | automatic (after every GitHub push to the master branch) | Same as **base** but with the default user set to "root". Required for Kubernetes. | | **lite** | manual (updated with every Vitess release) | Stripped down version of **base** e.g. source code and build dependencies are removed. Default image in our Kubernetes templates for minimized startup time. | @@ -47,7 +47,7 @@ If you are looking for a stable version of Vitess, use the **lite** image with a | Image | How (When) Updated | Description | | --- | --- | --- | -| **guestbook** | manual (updated with every Vitess release) | Vitess adaption of the Kubernetes guestbook example. Used to showcase sharding in Vitess. Dockerfile is located in [`examples/kubernetes/guestbook/`](https://github.com/youtube/vitess/tree/master/examples/kubernetes/guestbook). | +| **guestbook** | manual (updated with every Vitess release) | Vitess adaption of the Kubernetes guestbook example. Used to showcase sharding in Vitess. Dockerfile is located in [`examples/kubernetes/guestbook/`](https://github.com/vitessio/vitess/tree/master/examples/kubernetes/guestbook). | | **orchestrator** | manual | Binaries for [Orchestrator](https://github.com/github/orchestrator). It can be used with Vitess for automatic failovers. Currently not part of the Kubernetes Tutorial and only used in tests. | ### Internal Tools @@ -56,5 +56,5 @@ These images are used by the Vitess project for internal workflows and testing i | Image | How (When) Updated | Description | | --- | --- | --- | -| **publish-site** | manual | Contains [Jekyll](https://jekyllrb.com/) which we use to generate our [vitess.io](http://vitess.io) website from the Markdown files located in [doc/](https://github.com/youtube/vitess/tree/master/doc). | -| **keytar** | manual | Keytar is a Vitess testing framework to run our Kubernetes cluster tests. Dockerfile is located in [`test/cluster/keytar/`](https://github.com/youtube/vitess/tree/master/test/cluster/keytar). | +| **publish-site** | manual | Contains [Jekyll](https://jekyllrb.com/) which we use to generate our [vitess.io](http://vitess.io) website from the Markdown files located in [doc/](https://github.com/vitessio/vitess/tree/master/doc). | +| **keytar** | manual | Keytar is a Vitess testing framework to run our Kubernetes cluster tests. Dockerfile is located in [`test/cluster/keytar/`](https://github.com/vitessio/vitess/tree/master/test/cluster/keytar). | diff --git a/docker/bootstrap/README.md b/docker/bootstrap/README.md index 52d9a3e731d..9014d8bbb86 100644 --- a/docker/bootstrap/README.md +++ b/docker/bootstrap/README.md @@ -15,7 +15,7 @@ The `vitess/bootstrap` image comes in different flavors: **NOTE: Unlike the base image that builds Vitess itself, this bootstrap image will NOT be rebuilt automatically on every push to the Vitess master branch.** -To build a new bootstrap image, use the [build.sh](https://github.com/youtube/vitess/blob/master/docker/bootstrap/build.sh) +To build a new bootstrap image, use the [build.sh](https://github.com/vitessio/vitess/blob/master/docker/bootstrap/build.sh) script. First build the `common` image, then any flavors you want. For example: diff --git a/docker/k8s/Dockerfile b/docker/k8s/Dockerfile index b811fa28008..16a773d545b 100644 --- a/docker/k8s/Dockerfile +++ b/docker/k8s/Dockerfile @@ -50,7 +50,7 @@ COPY --from=base $VTTOP/config/mycnf/rbr.cnf /vt/config/mycnf/ RUN groupadd -r --gid 999 vitess && useradd -r -g vitess --uid 999 vitess && \ chown -R vitess:vitess /vt; -# TODO: remove when https://github.com/youtube/vitess/issues/3553 is fixed +# TODO: remove when https://github.com/vitessio/vitess/issues/3553 is fixed RUN apt-get update && \ apt-get upgrade -qq && \ apt-get install mysql-client -qq --no-install-recommends && \ diff --git a/docker/k8s/vttablet/Dockerfile b/docker/k8s/vttablet/Dockerfile index ff7b40e2a63..c55a41f5c94 100644 --- a/docker/k8s/vttablet/Dockerfile +++ b/docker/k8s/vttablet/Dockerfile @@ -15,7 +15,7 @@ COPY --from=k8s /vt/bin/vttablet /vt/bin/ # Copy certs to allow https calls COPY --from=k8s /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt -# TODO: remove when https://github.com/youtube/vitess/issues/3553 is fixed +# TODO: remove when https://github.com/vitessio/vitess/issues/3553 is fixed RUN apt-get update && \ apt-get upgrade -qq && \ apt-get install mysql-client -qq --no-install-recommends && \ diff --git a/go/vt/mysqlctl/mycnf_gen.go b/go/vt/mysqlctl/mycnf_gen.go index d1b49c1931e..348260f4627 100644 --- a/go/vt/mysqlctl/mycnf_gen.go +++ b/go/vt/mysqlctl/mycnf_gen.go @@ -167,7 +167,7 @@ func (cnf *Mycnf) fillMycnfTemplate(tmplSrc string) (string, error) { // for that range). // Such an ID may also be responsible for a mysqld crash in semi-sync code, // although we haven't been able to verify that yet. The issue for that is: -// https://github.com/youtube/vitess/issues/2280 +// https://github.com/vitessio/vitess/issues/2280 func (cnf *Mycnf) RandomizeMysqlServerID() error { // rand.Int(_, max) returns a value in the range [0, max). bigN, err := rand.Int(rand.Reader, big.NewInt(1<<31-100)) diff --git a/go/vt/vitessdriver/doc.go b/go/vt/vitessdriver/doc.go index 491977bfda8..6631f4b3be5 100644 --- a/go/vt/vitessdriver/doc.go +++ b/go/vt/vitessdriver/doc.go @@ -39,7 +39,7 @@ Using this SQL driver is as simple as: // Use "db" via the Golang sql interface. } -For a full example, please see: https://github.com/youtube/vitess/blob/master/examples/local/client.go +For a full example, please see: https://github.com/vitessio/vitess/blob/master/examples/local/client.go The full example is based on our tutorial for running Vitess locally: http://vitess.io/getting-started/local-instance/ @@ -62,21 +62,21 @@ The driver uses the V3 API which doesn't require you to specify routing information. You just send the query as if Vitess was a regular database. VTGate analyzes the query and uses additional metadata called VSchema to perform the necessary routing. See the vtgate v3 Features doc for an overview: -https://github.com/youtube/vitess/blob/master/doc/VTGateV3Features.md +https://github.com/vitessio/vitess/blob/master/doc/VTGateV3Features.md As of 12/2015, the VSchema creation is not documented yet as we are in the process of simplifying the VSchema definition and the overall process for creating one. If you want to create your own VSchema, we recommend to have a look at the VSchema from the vtgate v3 demo: -https://github.com/youtube/vitess/blob/master/examples/demo/schema +https://github.com/vitessio/vitess/blob/master/examples/demo/schema (The demo itself is interactive and can be run by executing "./run.py" in the "examples/demo/" directory.) The vtgate v3 design doc, which we will also update and simplify in the future, contains more details on the VSchema: -https://github.com/youtube/vitess/blob/master/doc/V3VindexDesign.md +https://github.com/vitessio/vitess/blob/master/doc/V3VindexDesign.md Isolation levels diff --git a/go/vt/vtctl/vtctl.go b/go/vt/vtctl/vtctl.go index 820a4511f2d..79703a7de4d 100644 --- a/go/vt/vtctl/vtctl.go +++ b/go/vt/vtctl/vtctl.go @@ -228,7 +228,7 @@ var commands = []commandGroup{ {"TabletExternallyReparented", commandTabletExternallyReparented, "", "Changes metadata in the topology server to acknowledge a shard master change performed by an external tool. See the Reparenting guide for more information:" + - "https://github.com/youtube/vitess/blob/master/doc/Reparenting.md#external-reparents."}, + "https://github.com/vitessio/vitess/blob/master/doc/Reparenting.md#external-reparents."}, {"ValidateShard", commandValidateShard, "[-ping-tablets] ", "Validates that all nodes that are reachable from this shard are consistent."}, diff --git a/go/vt/vtgate/vindexes/lookup_internal.go b/go/vt/vtgate/vindexes/lookup_internal.go index 66a69aa19a0..c26cf87ac24 100644 --- a/go/vt/vtgate/vindexes/lookup_internal.go +++ b/go/vt/vtgate/vindexes/lookup_internal.go @@ -50,7 +50,7 @@ func (lkp *lookupInternal) Init(lookupQueryParams map[string]string, autocommit, lkp.Upsert = upsert // TODO @rafael: update sel and ver to support multi column vindexes. This will be done - // as part of face 2 of https://github.com/youtube/vitess/issues/3481 + // as part of face 2 of https://github.com/vitessio/vitess/issues/3481 // For now multi column behaves as a single column for Map and Verify operations lkp.sel = fmt.Sprintf("select %s from %s where %s = :%s", lkp.To, lkp.Table, lkp.FromColumns[0], lkp.FromColumns[0]) lkp.ver = fmt.Sprintf("select %s from %s where %s = :%s and %s = :%s", lkp.FromColumns[0], lkp.Table, lkp.FromColumns[0], lkp.FromColumns[0], lkp.To, lkp.To) diff --git a/helm/vitess/Chart.yaml b/helm/vitess/Chart.yaml index 368ea4d0232..902611d82c0 100644 --- a/helm/vitess/Chart.yaml +++ b/helm/vitess/Chart.yaml @@ -13,7 +13,7 @@ keywords: - shard home: http://vitess.io sources: - - https://github.com/youtube/vitess + - https://github.com/vitessio/vitess maintainers: - name: Vitess Project email: vitess@googlegroups.com diff --git a/java/client/src/main/java/io/vitess/client/Proto.java b/java/client/src/main/java/io/vitess/client/Proto.java index 1de01a23f68..a6e2449277b 100644 --- a/java/client/src/main/java/io/vitess/client/Proto.java +++ b/java/client/src/main/java/io/vitess/client/Proto.java @@ -59,7 +59,7 @@ public class Proto { * *

* Errors returned by Vitess are documented in the - * vtrpc proto. + * vtrpc proto. */ public static void checkError(RPCError error) throws SQLException { if (error != null) { diff --git a/java/client/src/main/java/io/vitess/client/RpcClient.java b/java/client/src/main/java/io/vitess/client/RpcClient.java index 65a6e6d2020..68015380044 100644 --- a/java/client/src/main/java/io/vitess/client/RpcClient.java +++ b/java/client/src/main/java/io/vitess/client/RpcClient.java @@ -59,7 +59,7 @@ public interface RpcClient extends Closeable { * Sends a single query using the VTGate V3 API. * *

See the - * proto + * proto * definition for canonical documentation on this VTGate API. */ ListenableFuture execute(Context ctx, ExecuteRequest request) @@ -69,7 +69,7 @@ ListenableFuture execute(Context ctx, ExecuteRequest request) * Sends a single query to a set of shards. * *

See the - * proto + * proto * definition for canonical documentation on this VTGate API. */ ListenableFuture executeShards(Context ctx, ExecuteShardsRequest request) @@ -79,7 +79,7 @@ ListenableFuture executeShards(Context ctx, ExecuteShards * Sends a query with a set of keyspace IDs. * *

See the - * proto + * proto * definition for canonical documentation on this VTGate API. */ ListenableFuture executeKeyspaceIds( @@ -89,7 +89,7 @@ ListenableFuture executeKeyspaceIds( * Sends a query with a set of key ranges. * *

See the - * proto + * proto * definition for canonical documentation on this VTGate API. */ ListenableFuture executeKeyRanges( @@ -99,7 +99,7 @@ ListenableFuture executeKeyRanges( * Sends a query with a set of entity IDs. * *

See the - * proto + * proto * definition for canonical documentation on this VTGate API. */ ListenableFuture executeEntityIds( @@ -109,7 +109,7 @@ ListenableFuture executeEntityIds( * Sends a list of queries using the VTGate V3 API. * *

See the - * proto + * proto * definition for canonical documentation on this VTGate API. */ ListenableFuture executeBatch(Context ctx, Vtgate.ExecuteBatchRequest request) @@ -119,7 +119,7 @@ ListenableFuture executeBatch(Context ctx, Vtgate.E * Sends a list of queries to a set of shards. * *

See the - * proto + * proto * definition for canonical documentation on this VTGate API. */ ListenableFuture executeBatchShards( @@ -129,7 +129,7 @@ ListenableFuture executeBatchShards( * Sends a list of queries with keyspace ids as bind variables. * *

See the - * proto + * proto * definition for canonical documentation on this VTGate API. */ ListenableFuture executeBatchKeyspaceIds( @@ -144,7 +144,7 @@ ListenableFuture executeBatchKeyspaceIds( * next chunk of results is received from the server. * *

See the - * proto + * proto * definition for canonical documentation on this VTGate API. */ StreamIterator streamExecute(Context ctx, StreamExecuteRequest request) @@ -159,7 +159,7 @@ StreamIterator streamExecute(Context ctx, StreamExecuteRequest requ * next chunk of results is received from the server. * *

See the - * proto + * proto * definition for canonical documentation on this VTGate API. */ StreamIterator streamExecuteShards(Context ctx, StreamExecuteShardsRequest request) @@ -174,7 +174,7 @@ StreamIterator streamExecuteShards(Context ctx, StreamExecuteShards * next chunk of results is received from the server. * *

See the - * proto + * proto * definition for canonical documentation on this VTGate API. */ StreamIterator streamExecuteKeyspaceIds( @@ -189,7 +189,7 @@ StreamIterator streamExecuteKeyspaceIds( * next chunk of results is received from the server. * *

See the - * proto + * proto * definition for canonical documentation on this VTGate API. */ StreamIterator streamExecuteKeyRanges( @@ -199,7 +199,7 @@ StreamIterator streamExecuteKeyRanges( * Starts a transaction. * *

See the - * proto + * proto * definition for canonical documentation on this VTGate API. */ ListenableFuture begin(Context ctx, BeginRequest request) throws SQLException; @@ -208,7 +208,7 @@ StreamIterator streamExecuteKeyRanges( * Commits a transaction. * *

See the - * proto + * proto * definition for canonical documentation on this VTGate API. */ ListenableFuture commit(Context ctx, CommitRequest request) throws SQLException; @@ -217,7 +217,7 @@ StreamIterator streamExecuteKeyRanges( * Rolls back a pending transaction. * *

See the - * proto + * proto * definition for canonical documentation on this VTGate API. */ ListenableFuture rollback(Context ctx, RollbackRequest request) @@ -227,7 +227,7 @@ ListenableFuture rollback(Context ctx, RollbackRequest request * Splits a query into smaller queries. * *

See the - * proto + * proto * definition for canonical documentation on this VTGate API. */ ListenableFuture splitQuery(Context ctx, SplitQueryRequest request) @@ -237,7 +237,7 @@ ListenableFuture splitQuery(Context ctx, SplitQueryRequest r * Returns a list of serving keyspaces. * *

See the - * proto + * proto * definition for canonical documentation on this VTGate API. */ ListenableFuture getSrvKeyspace( diff --git a/java/client/src/main/java/io/vitess/client/VTGateConn.java b/java/client/src/main/java/io/vitess/client/VTGateConn.java index 26dd5f4af79..34f077944d5 100644 --- a/java/client/src/main/java/io/vitess/client/VTGateConn.java +++ b/java/client/src/main/java/io/vitess/client/VTGateConn.java @@ -75,7 +75,7 @@ * *

* See the VitessClientExample + * "https://github.com/vitessio/vitess/blob/master/java/example/src/main/java/io/vitess/example/VitessClientExample.java">VitessClientExample * for a usage example. * *

diff --git a/java/hadoop/src/main/java/io/vitess/hadoop/README.md b/java/hadoop/src/main/java/io/vitess/hadoop/README.md index a1dc0d27d56..65334894384 100644 --- a/java/hadoop/src/main/java/io/vitess/hadoop/README.md +++ b/java/hadoop/src/main/java/io/vitess/hadoop/README.md @@ -14,7 +14,7 @@ primary key (id)) Engine=InnoDB; Let's say we want to write a MapReduce job that imports this table from Vitess to HDFS where each row is turned into a CSV record in HDFS. -We can use [VitessInputFormat](https://github.com/youtube/vitess/blob/master/java/hadoop/src/main/java/io/vitess/hadoop/VitessInputFormat.java), an implementation of Hadoop's [InputFormat](http://hadoop.apache.org/docs/stable/api/org/apache/hadoop/mapred/InputFormat.html), for that. With VitessInputFormat, rows from the source table are streamed to the mapper task. Each input record has a [NullWritable](https://hadoop.apache.org/docs/r2.2.0/api/org/apache/hadoop/io/NullWritable.html) key (no key, really), and [RowWritable](https://github.com/youtube/vitess/blob/master/java/hadoop/src/main/java/io/vitess/hadoop/RowWritable.java) as value, which is a writable implementation for the entire row's contents. +We can use [VitessInputFormat](https://github.com/vitessio/vitess/blob/master/java/hadoop/src/main/java/io/vitess/hadoop/VitessInputFormat.java), an implementation of Hadoop's [InputFormat](http://hadoop.apache.org/docs/stable/api/org/apache/hadoop/mapred/InputFormat.html), for that. With VitessInputFormat, rows from the source table are streamed to the mapper task. Each input record has a [NullWritable](https://hadoop.apache.org/docs/r2.2.0/api/org/apache/hadoop/io/NullWritable.html) key (no key, really), and [RowWritable](https://github.com/vitessio/vitess/blob/master/java/hadoop/src/main/java/io/vitess/hadoop/RowWritable.java) as value, which is a writable implementation for the entire row's contents. Here is an example implementation of our mapper, which transforms each row into a CSV Text. @@ -55,11 +55,11 @@ public static void main(String[] args) { } ``` -Refer [this integration test](https://github.com/youtube/vitess/blob/master/java/hadoop/src/test/java/io/vitess/hadoop/MapReduceIT.java) for a working example a MapReduce job on Vitess. +Refer [this integration test](https://github.com/vitessio/vitess/blob/master/java/hadoop/src/test/java/io/vitess/hadoop/MapReduceIT.java) for a working example a MapReduce job on Vitess. ## How it Works -VitessInputFormat relies on VtGate's [SplitQuery](https://github.com/youtube/vitess/blob/21515f5c1a85c0054ddf7d2ff068702670ab93b5/proto/vtgateservice.proto#L98) RPC to obtain the input splits. This RPC method accepts a SplitQueryRequest which consists of an input query and the desired number of splits (splitCount). SplitQuery returns SplitQueryResult, which has a list of SplitQueryParts. SplitQueryPart consists of a KeyRangeQuery and a size estimate of how many rows this sub-query might return. SplitQueryParts return rows that are mutually exclusive and collectively exhaustive - all rows belonging to the original input query will be returned by one and exactly one SplitQueryPart. +VitessInputFormat relies on VtGate's [SplitQuery](https://github.com/vitessio/vitess/blob/21515f5c1a85c0054ddf7d2ff068702670ab93b5/proto/vtgateservice.proto#L98) RPC to obtain the input splits. This RPC method accepts a SplitQueryRequest which consists of an input query and the desired number of splits (splitCount). SplitQuery returns SplitQueryResult, which has a list of SplitQueryParts. SplitQueryPart consists of a KeyRangeQuery and a size estimate of how many rows this sub-query might return. SplitQueryParts return rows that are mutually exclusive and collectively exhaustive - all rows belonging to the original input query will be returned by one and exactly one SplitQueryPart. VitessInputFormat turns each SplitQueryPart into a mapper task. The number of splits generated may not be exactly equal to the desired split count specified in the input. Specifically, if the desired split count is not a multiple of the number of shards, then VtGate will round it up to the next bigger multiple of number of shards. diff --git a/java/pom.xml b/java/pom.xml index 840b4e06104..b81691afbfe 100644 --- a/java/pom.xml +++ b/java/pom.xml @@ -38,18 +38,18 @@ Apache Version 2.0 - https://github.com/youtube/vitess/blob/master/LICENSE + https://github.com/vitessio/vitess/blob/master/LICENSE manual - scm:git:git@github.com:youtube/vitess.git - scm:git:git@github.com:youtube/vitess.git - http://github.com/youtube/vitess/tree/master + scm:git:git@github.com:vitessio/vitess.git + scm:git:git@github.com:vitessio/vitess.git + http://github.com/vitessio/vitess/tree/master GitHub - https://github.com/youtube/vitess/issues + https://github.com/vitessio/vitess/issues diff --git a/test/cluster/keytar/config/vitess_config.yaml b/test/cluster/keytar/config/vitess_config.yaml index f9d551bca5b..ad85cbe4692 100644 --- a/test/cluster/keytar/config/vitess_config.yaml +++ b/test/cluster/keytar/config/vitess_config.yaml @@ -19,7 +19,7 @@ install: config: - docker_image: vitess/root github: - repo: youtube/vitess + repo: vitessio/vitess repo_prefix: src/vitess.io/vitess environment: sandbox: test/cluster/sandbox/vitess_kubernetes_sandbox.py diff --git a/test/cluster/keytar/keytar_test.py b/test/cluster/keytar/keytar_test.py index 2bcc16ba39d..01855cc7bf1 100644 --- a/test/cluster/keytar/keytar_test.py +++ b/test/cluster/keytar/keytar_test.py @@ -1,11 +1,11 @@ # Copyright 2017 Google Inc. -# +# # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at -# +# # http://www.apache.org/licenses/LICENSE-2.0 -# +# # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. @@ -42,22 +42,22 @@ def test_validate_request(self): keytar._validate_request('foo', {}) def test_get_download_github_repo_args(self): - github_config = {'repo': 'youtube/vitess', 'repo_prefix': 'foo'} + github_config = {'repo': 'vitessio/vitess', 'repo_prefix': 'foo'} github_clone_args, repo_dir = ( keytar._get_download_github_repo_args('/tmp', github_config)) self.assertEquals( github_clone_args, - ['git', 'clone', 'https://github.com/youtube/vitess', '/tmp/foo']) + ['git', 'clone', 'https://github.com/vitessio/vitess', '/tmp/foo']) self.assertEquals('/tmp/foo', repo_dir) github_config = { - 'repo': 'youtube/vitess', 'repo_prefix': 'foo', 'branch': 'bar'} + 'repo': 'vitessio/vitess', 'repo_prefix': 'foo', 'branch': 'bar'} github_clone_args, repo_dir = ( keytar._get_download_github_repo_args('/tmp', github_config)) self.assertEquals( github_clone_args, - ['git', 'clone', 'https://github.com/youtube/vitess', '/tmp/foo', '-b', + ['git', 'clone', 'https://github.com/vitessio/vitess', '/tmp/foo', '-b', 'bar']) self.assertEquals('/tmp/foo', repo_dir) diff --git a/test/cluster/keytar/test_config.yaml b/test/cluster/keytar/test_config.yaml index 6f5c51b524d..308c6de7026 100644 --- a/test/cluster/keytar/test_config.yaml +++ b/test/cluster/keytar/test_config.yaml @@ -4,7 +4,7 @@ install: config: - docker_image: test/image github: - repo: youtube/vitess + repo: vitessio/vitess repo_prefix: src/vitess.io/vitess before_test: - touch /tmp/test_file diff --git a/test/legacy_resharding.py b/test/legacy_resharding.py index eaa4a8fe60e..5640c6043ba 100755 --- a/test/legacy_resharding.py +++ b/test/legacy_resharding.py @@ -1,13 +1,13 @@ #!/usr/bin/env python # # Copyright 2017 Google Inc. -# +# # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at -# +# # http://www.apache.org/licenses/LICENSE-2.0 -# +# # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. @@ -24,7 +24,7 @@ This is the case for the "timestamps" table in this end-to-end test. The reason why only LegacySplitClone supports this use case is because the new -resharding clone code (as of https://github.com/youtube/vitess/pull/1796) +resharding clone code (as of https://github.com/vitessio/vitess/pull/1796) requires to sort rows by their primary key. Whereas LegacySplitClone does a simple copy and always assumes that the tables on the destination are empty, the SplitClone command can diff the source and destination tables. In case of diff --git a/test/resharding.py b/test/resharding.py index ac05bc8a424..f5a74d45c72 100755 --- a/test/resharding.py +++ b/test/resharding.py @@ -262,7 +262,7 @@ def _insert_startup_values(self): if base_sharding.use_rbr: self._insert_value(shard_1_master, 'no_pk', 1, 'msg1', 0xA000000000000000) - # TODO(github.com/youtube/vitess/issues/2880): Add more rows here such + # TODO(github.com/vitessio/vitess/issues/2880): Add more rows here such # clone and diff would break when the insertion order on source and # dest shards is different. @@ -518,7 +518,7 @@ def test_resharding(self): shard_2_master.start_vttablet(wait_for_state=None, binlog_use_v3_resharding_mode=False) shard_3_master.start_vttablet(wait_for_state=None, - binlog_use_v3_resharding_mode=False) + binlog_use_v3_resharding_mode=False) for t in [shard_2_replica1, shard_2_replica2, shard_2_rdonly1, shard_3_replica, shard_3_rdonly1]: t.start_vttablet(wait_for_state=None, @@ -563,7 +563,7 @@ def test_resharding(self): # Run vtworker as daemon for the following SplitClone commands. worker_proc, worker_port, worker_rpc_port = utils.run_vtworker_bg( ['--cell', 'test_nj', '--command_display_interval', '10ms', - '--use_v3_resharding_mode=false'], + '--use_v3_resharding_mode=false'], auto_log=True) # Copy the data from the source to the destination shards. diff --git a/test/schema.py b/test/schema.py index 1ba7fc73be2..d7fc2f4994d 100755 --- a/test/schema.py +++ b/test/schema.py @@ -1,13 +1,13 @@ #!/usr/bin/env python # Copyright 2017 Google Inc. -# +# # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at -# +# # http://www.apache.org/licenses/LICENSE-2.0 -# +# # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. @@ -252,7 +252,7 @@ def test_schema_changes_drop_and_create(self): consider previous statements within the same ApplySchema command. For example, a CREATE after DROP must not fail: When CREATE is checked, DROP must have been executed first. - See: https://github.com/youtube/vitess/issues/1731#issuecomment-222914389 + See: https://github.com/vitessio/vitess/issues/1731#issuecomment-222914389 """ self._apply_initial_schema() self._check_tables(shard_0_master, 4) diff --git a/travis/install_grpc.sh b/travis/install_grpc.sh index a34fc699849..ee1da6773f0 100755 --- a/travis/install_grpc.sh +++ b/travis/install_grpc.sh @@ -51,7 +51,7 @@ if [ `uname -s` == "Darwin" ]; then export GRPC_PYTHON_BUILD_WITH_CYTHON=1 $PIP install Cython - # Work-around macOS Sierra blocker, see: https://github.com/youtube/vitess/issues/2115 + # Work-around macOS Sierra blocker, see: https://github.com/vitessio/vitess/issues/2115 # TODO(mberlin): Remove this when the underlying issue is fixed and available # in the gRPC version used by Vitess. # See: https://github.com/google/protobuf/issues/2182