Swap internal doc. refs to relative links.

This commit addresses issue #1571, which requests that all internal
Kubernetes links are swapped to relative ones to better facilitate
browsing of documentation on local forks, not to mention make the
documentation have less needless boilerplate.

CONTRIBUTING.md

@@ -21,7 +21,7 @@ Follow either of the two links above to access the appropriate CLA and instructi
 
 ## Protocols for Collaborative Development
 
-Please read [this doc](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/collab.md) for information on how we're running development for the project.
+Please read [this doc](docs/collab.md) for information on how we're running development for the project.
 
 ## Adding dependencies
 

DESIGN.md

@@ -52,7 +52,7 @@ While Docker itself works with individual containers, Kubernetes provides higher
 
 A _pod_ (as in a pod of whales or pea pod) is a relatively tightly coupled group of containers that are scheduled onto the same host. It models an application-specific "virtual host" in a containerized environment. Pods serve as units of scheduling, deployment, and horizontal scaling/replication, share fate, and share some resources, such as storage volumes and IP addresses.
 
-[More details on pods](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/pods.md).
+[More details on pods](docs/pods.md).
 
 ### Labels
 
@@ -70,7 +70,7 @@ The set of pods that a `service` targets is defined with a label selector. Simil
 
 For management convenience and consistency, `services` and `replicationControllers` may themselves have labels and would generally carry the labels their corresponding pods have in common.
 
-[More details on labels](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/labels.md).
+[More details on labels](docs/labels.md).
 
 ## The Kubernetes Node
 
@@ -138,7 +138,7 @@ The heavy lifting of configuring the VMs is done by [SaltStack](http://www.salts
 The bootstrapping works like this:
 
 1. The `kube-up.sh` script uses the GCE [`startup-script`](https://developers.google.com/compute/docs/howtos/startupscript) mechanism for both the master node and the minion nodes.
-  * For the minion, this simply configures and installs SaltStack.  The network range that this minion is assigned is baked into the startup-script for that minion (see [the networking doc](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/networking.md) for more details).
+  * For the minion, this simply configures and installs SaltStack.  The network range that this minion is assigned is baked into the startup-script for that minion (see [the networking doc](docs/networking.md) for more details).
   * For the master, the release files are downloaded from GCS and unpacked.  Various parts (specifically the SaltStack configuration) are installed in the right places.
 2. SaltStack then installs the necessary servers on each node.
   * All go code is currently downloaded to each machine and compiled at install time.

README.md

@@ -1,7 +1,7 @@
 # Kubernetes
 Kubernetes is an open source implementation of container cluster management.
 
-[Kubernetes Design Document](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/DESIGN.md) - [Kubernetes @ Google I/O 2014](http://youtu.be/tsk0pWf4ipw)
+[Kubernetes Design Document](DESIGN.md) - [Kubernetes @ Google I/O 2014](http://youtu.be/tsk0pWf4ipw)
 
 [![GoDoc](https://godoc.org/github.com/GoogleCloudPlatform/kubernetes?status.png)](https://godoc.org/github.com/GoogleCloudPlatform/kubernetes)
 [![Travis](https://travis-ci.org/GoogleCloudPlatform/kubernetes.svg?branch=master)](https://travis-ci.org/GoogleCloudPlatform/kubernetes)
@@ -26,9 +26,9 @@ While the concepts and architecture in Kubernetes represent years of experience
   * [Circle CI](https://circleci.com/docs/docker#google-compute-engine-and-kubernetes)
   * [Digital Ocean](https://github.com/bketelsen/coreos-kubernetes-digitalocean)
   * [OpenStack](https://developer.rackspace.com/blog/running-coreos-and-kubernetes/)
-* [kubecfg command line tool](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/cli.md)
+* [kubecfg command line tool](docs/cli.md)
 * [Kubernetes API Documentation](http://cdn.rawgit.com/GoogleCloudPlatform/kubernetes/31a0daae3627c91bc96e1f02a6344cd76e294791/api/kubernetes.html)
-* [Kubernetes Client Libraries](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/client-libraries.md)
+* [Kubernetes Client Libraries](docs/client-libraries.md)
 * [Discussion and Community Support](#community-discussion-and-support)
 * [Hacking on Kubernetes](#development)
 * [Hacking on Kubernetes Salt configuration](docs/salt.md)
@@ -38,8 +38,8 @@ While the concepts and architecture in Kubernetes represent years of experience
 
 Check out examples of Kubernetes in action, and community projects in the larger ecosystem:
 
-* [Detailed example application](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/guestbook/README.md)
-* [Example of dynamic updates](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/update-demo/README.md)
+* [Detailed example application](examples/guestbook/README.md)
+* [Example of dynamic updates](examples/update-demo/README.md)
 * [Cluster monitoring with heapster and cAdvisor](https://github.com/GoogleCloudPlatform/heapster)
 * [Community projects](https://github.com/GoogleCloudPlatform/kubernetes/wiki/Kubernetes-Community)
 
@@ -178,7 +178,7 @@ hack/e2e-test.sh 1 1 1
 ```
 
 ### Testing out flaky tests
-[Instructions here](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/flaky-tests.md)
+[Instructions here](docs/flaky-tests.md)
 
 ### Add/Update dependencies
 

docs/access.md

@@ -141,7 +141,7 @@ Improvements:
 ###Namespaces
 K8s will have a have a `namespace` API object.  It is similar to a Google Compute Engine `project`.  It provides a namespace for objects created by a group of people co-operating together, preventing name collisions with non-cooperating groups.  It also serves as a reference point for authorization policies.
 
-Namespaces are described in [namespace.md](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/namespaces.md).
+Namespaces are described in [namespace.md](docs/namespaces.md).
 
 In the Enterprise Profile:
    - a `userAccount` may have permission to access several `namespace`s.
@@ -151,7 +151,7 @@ In the Simple Profile:
 
 Namespaces versus userAccount vs Labels:
 - `userAccount`s are intended for audit logging (both name and UID should be logged), and to define who has access to `namespace`s.
-- `labels` (see [docs/labels.md](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/labels.md)) should be used to distinguish pods, users, and other objects that cooperate towards a common goal but are different in some way, such as version, or responsibilities.  
+- `labels` (see [docs/labels.md](docs/labels.md)) should be used to distinguish pods, users, and other objects that cooperate towards a common goal but are different in some way, such as version, or responsibilities.
 - `namespace`s prevent name collisions between uncoordinated groups of people, and provide a place to attach common policies for co-operating groups of people.
 
 
@@ -212,7 +212,7 @@ Policy objects may be applicable only to a single namespace or to all namespaces
 
 ## Accounting
 
-The API should have a `quota` concept (see https://github.com/GoogleCloudPlatform/kubernetes/issues/442).  A quota object relates a namespace (and optionally a label selector) to a maximum quantity of resources that may be used (see [resources.md](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/resources.md)).
+The API should have a `quota` concept (see https://github.com/GoogleCloudPlatform/kubernetes/issues/442).  A quota object relates a namespace (and optionally a label selector) to a maximum quantity of resources that may be used (see [resources.md](docs/resources.md)).
 
 Initially:
 - a `quota` object is immutable.
@@ -246,5 +246,3 @@ Initial implementation:
 Improvements:
 - API server does logging instead.
 - Policies to drop logging for high rate trusted API calls, or by users performing audit or other sensitive functions.
-
-

docs/container-environment.md

@@ -7,7 +7,7 @@ This document describes the environment for Kubelet managed containers on a Kube
 This cluster information makes it possible to build applications that are *cluster aware*.  
 Additionally, the Kubernetes container environment defines a series of signals that are surfaced to optional signal handlers defined as part of individual containers.  Container signals are somewhat analagous to operating system signals in a traditional process model.   However these signals are designed to make it easier to build reliable, scalable cloud applications in the Kubernetes cluster.  Containers that participate in this cluster lifecycle become *cluster native*. 
 
-Another important part of the container environment is the file system that is available to the container.  In Kubernetes, the filesystem is a combination of the Docker image and pod volumes. The design and usage of pod volumes is described in its own [document](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/volumes.md)
+Another important part of the container environment is the file system that is available to the container.  In Kubernetes, the filesystem is a combination of the Docker image and pod volumes. The design and usage of pod volumes is described in its own [document](docs/volumes.md)
 
 
 The following sections describe both the cluster information provided to containers, as well as the signals and life-cycle that allows containers to interact with the management system.

docs/networking.md

@@ -2,7 +2,7 @@
 
 ## Model and motivation
 
-Kubernetes deviates from the default Docker networking model.  The goal is for each [pod](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/pods.md) to have an IP in a flat shared networking namespace that has full communication with other physical computers and containers across the network.  IP-per-pod creates a clean, backward-compatible model where pods can be treated much like VMs or physical hosts from the perspectives of port allocation, networking, naming, service discovery, load balancing, application configuration, and migration.
+Kubernetes deviates from the default Docker networking model.  The goal is for each [pod](docs/pods.md) to have an IP in a flat shared networking namespace that has full communication with other physical computers and containers across the network.  IP-per-pod creates a clean, backward-compatible model where pods can be treated much like VMs or physical hosts from the perspectives of port allocation, networking, naming, service discovery, load balancing, application configuration, and migration.
 
 OTOH, dynamic port allocation requires supporting both static ports (e.g., for externally accessible services) and dynamically allocated ports, requires partitioning centrally allocated and locally acquired dynamic ports, complicates scheduling (since ports are a scarce resource), is inconvenient for users, complicates application configuration, is plagued by port conflicts and reuse and exhaustion, requires non-standard approaches to naming (e.g., etcd rather than DNS), requires proxies and/or redirection for programs using standard naming/addressing mechanisms (e.g., web browsers), requires watching and cache invalidation for address/port changes for instances in addition to watching group membership changes, and obstructs container/pod migration (e.g., using CRIU). NAT introduces additional complexity by fragmenting the addressing space, which breaks self-registration mechanisms, among other problems.
 
@@ -27,7 +27,7 @@ Ports mapped in from the 'main IP' (and hence the internet if the right firewall
 We start Docker with:
     DOCKER_OPTS="--bridge cbr0 --iptables=false"
 
-We set up this bridge on each node with SaltStack, in [container_bridge.py](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/cluster/saltbase/salt/_states/container_bridge.py).
+We set up this bridge on each node with SaltStack, in [container_bridge.py](cluster/saltbase/salt/_states/container_bridge.py).
 
     cbr0:
       container_bridge.ensure:
@@ -65,7 +65,7 @@ Docker allocates IP addresses from a bridge we create on each node, using its
 
 ### Other networking implementation examples
 With the primary aim of providing IP-per-pod-model, other implementations exist to serve the purpose outside of GCE.
-  - [OpenVSwitch with GRE/VxLAN](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/ovs-networking.md)
+  - [OpenVSwitch with GRE/VxLAN](docs/ovs-networking.md)
   - [Flannel](https://github.com/coreos/flannel#flannel)
 
 ## Challenges and future work
@@ -105,4 +105,3 @@ Another approach could be to create a new host interface alias for each pod, if
 ### IPv6
 
 IPv6 would be a nice option, also, but we can't depend on it yet. Docker support is in progress: [Docker issue #2974](https://github.com/dotcloud/docker/issues/2974), [Docker issue #6923](https://github.com/dotcloud/docker/issues/6923), [Docker issue #6975](https://github.com/dotcloud/docker/issues/6975). Additionally, direct ipv6 assignment to instances doesn't appear to be supported by major cloud providers (e.g., AWS EC2, GCE) yet. We'd happily take pull requests from people running Kubernetes on bare metal, though. :-)
-

docs/pods.md

@@ -12,7 +12,7 @@ Like running containers, pods are considered to be relatively ephemeral rather t
 
 Pods facilitate data sharing and communication among their constituents.
 
-The containers in the pod all use the same network namespace/IP and port space, and can find and communicate with each other using localhost. Each pod has an IP address in a flat shared networking namespace that has full communication with other physical computers and containers across the network. The hostname is set to the pod's Name for the containers within the pod. [More details on networking](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/networking.md).
+The containers in the pod all use the same network namespace/IP and port space, and can find and communicate with each other using localhost. Each pod has an IP address in a flat shared networking namespace that has full communication with other physical computers and containers across the network. The hostname is set to the pod's Name for the containers within the pod. [More details on networking](docs/networking.md).
 
 In addition to defining the containers that run in the pod, the pod specifies a set of shared storage volumes. Volumes enable data to survive container restarts and to be shared among the containers within the pod.
 

docs/ux.md

@@ -24,7 +24,7 @@ The Kubernetes user interface is a query-based visualization of the Kubernetes A
 _GroupBy_ takes a label ```key``` as a parameter, places all objects with the same value for that key within a single group. For example ```/groups/host/selector``` groups pods by host.  ```/groups/name/selector``` groups pods by name.  Groups are hiearchical, for example ```/groups/name/host/selector``` first groups by pod name, and then by host.
 
 #### Select
-Select takes a [label selector](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/labels.md) and uses it to filter, so only resources which match that label selector are displayed.  For example, ```/groups/host/selector/name=frontend```, shows pods, grouped by host, which have a label with the name `frontend`.
+Select takes a [label selector](docs/labels.md) and uses it to filter, so only resources which match that label selector are displayed.  For example, ```/groups/host/selector/name=frontend```, shows pods, grouped by host, which have a label with the name `frontend`.
 
 
 ## Rebuilding the UX

examples/walkthrough/README.md

@@ -3,7 +3,7 @@
 ## Pods
 The first atom of Kubernetes is a _pod_.  A pod is a collection of containers that are symbiotically group.
 
-See [pods](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/pods.md) for more details.
+See [pods](docs/pods.md) for more details.
 
 ### Intro
 
@@ -23,7 +23,7 @@ desiredState:
 
 A pod definition is a declaration of a _desired state_.  Desired state is a really important part of Kubernetes.  Many things present a desired state to the system, and it is Kubernetes' responsibility to make sure that the current state matches the desired state.  For example, when you create a Pod, you declare that you want the containers in it to be running.  If the containers happen to not be running (program failure, ...), Kubernetes will continue to (re)create them for you until you delete the Pod.
 
-See the [design document](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/DESIGN.md) for more details.
+See the [design document](DESIGN.md) for more details.
 
 ### Volumes
 
@@ -75,7 +75,7 @@ In Kubernetes, ```emptyDir``` Volumes live for the lifespan of the Pod, which is
 
 If you want to mount a directory that already exists in the file system (e.g. ```/var/logs```) you can use the ```hostDir``` directive.
 
-See [volumes](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/volumes.md) for more details.
+See [volumes](docs/volumes.md) for more details.
 
 ### Multiple Containers