Fixing links to devel/ to point to kubernetes master repo

docs/user-guide/accessing-the-cluster.md

@@ -96,7 +96,7 @@ with future high-availability support.
 
 ### Programmatic access to the API
 
-There are [client libraries](/docs/devel/client-libraries) for accessing the API
+There are [client libraries](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/client-libraries.md) for accessing the API
 from several languages.  The Kubernetes project-supported
 [Go](http://releases.k8s.io/{{page.githubbranch}}/pkg/client/)
 client library can use the same [kubeconfig file](/docs/user-guide/kubeconfig-file)

docs/user-guide/deployments.md

@@ -206,7 +206,7 @@ As with all other Kubernetes configs, a Deployment needs `apiVersion`, `kind`, a
 `metadata` fields.  For general information about working with config files,
 see [here](/docs/user-guide/deploying-applications), [here](/docs/user-guide/configuring-containers), and [here](/docs/user-guide/working-with-resources).
 
-A Deployment also needs a [`.spec` section](/docs/devel/api-conventions/#spec-and-status).
+A Deployment also needs a [`.spec` section](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status).
 
 ### Pod Template
 

docs/user-guide/downward-api/volume/index.md

@@ -2,7 +2,7 @@
 ---
 
 Following this example, you will create a pod with a downward API volume.
-A downward API volume is a k8s volume plugin with the ability to save some pod information in a plain text file. The pod information can be  for example some [metadata](/docs/devel/api-conventions/#metadata).
+A downward API volume is a k8s volume plugin with the ability to save some pod information in a plain text file. The pod information can be  for example some [metadata](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#metadata).
 
 Supported metadata fields:
 

docs/user-guide/index.md

@@ -4,7 +4,7 @@
 * TOC
 {:toc}
 
-The user guide is intended for anyone who wants to run programs and services on an existing Kubernetes cluster.  Setup and administration of a Kubernetes cluster is described in the [Cluster Admin Guide](/docs/admin/). The [Developer Guide](/docs/devel/) is for anyone wanting to either write code which directly accesses the Kubernetes API, or to contribute directly to the Kubernetes project.
+The user guide is intended for anyone who wants to run programs and services on an existing Kubernetes cluster.  Setup and administration of a Kubernetes cluster is described in the [Cluster Admin Guide](/docs/admin/). The [Developer Guide](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/) is for anyone wanting to either write code which directly accesses the Kubernetes API, or to contribute directly to the Kubernetes project.
 
 Please ensure you have completed the [prerequisites for running examples from the user guide](/docs/user-guide/prereqs).
 

docs/user-guide/ingress.md

@@ -69,7 +69,7 @@ rules:
 
 __Lines 1-4__: As with all other Kubernetes config, an Ingress needs `apiVersion`, `kind`, and `metadata` fields.  For general information about working with config files, see [here](/docs/user-guide/simple-yaml), [here](/docs/user-guide/configuring-containers), and [here](/docs/user-guide/working-with-resources).
 
-__Lines 5-7__: Ingress [spec](/docs/devel/api-conventions/#spec-and-status) has all the information needed to configure a loadbalancer or proxy server. Most importantly, it contains a list of rules matched against all incoming requests. Currently the Ingress resource only supports http rules.
+__Lines 5-7__: Ingress [spec](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status) has all the information needed to configure a loadbalancer or proxy server. Most importantly, it contains a list of rules matched against all incoming requests. Currently the Ingress resource only supports http rules.
 
 __Lines 8-9__: Each http rule contains the following information: A host (eg: foo.bar.com, defaults to * in this example), a list of paths (eg: /testpath) each of which has an associated backend (test:80). Both the host and path must match the content of an incoming request before the loadbalancer directs traffic to the backend.
 

docs/user-guide/jobs.md

@@ -71,7 +71,7 @@ As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `meta
 general information about working with config files, see [here](/docs/user-guide/simple-yaml),
 [here](/docs/user-guide/configuring-containers), and [here](working-with-resources).
 
-A Job also needs a [`.spec` section](/docs/devel/api-conventions/#spec-and-status).
+A Job also needs a [`.spec` section](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status).
 
 ### Pod Template
 
@@ -110,7 +110,7 @@ think that those pods were created by it.  Kubernetes will not stop you from doi
 By default, a Job is complete when one Pod runs to successful completion.  You can also specify that
 this needs to happen multiple times by specifying `.spec.completions` with a value greater than 1.
 When multiple completions are requested, each Pod created by the Job controller has an identical
-[`spec`](/docs/devel/api-conventions/#spec-and-status).  In particular, all pods will have
+[`spec`](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status).  In particular, all pods will have
 the same command line and the same image, the same volumes, and mostly the same environment
 variables.  It is up to the user to arrange for the pods to do work on different things.  For
 example, the pods might all access a shared work queue service to acquire work units.

docs/user-guide/logging.md

@@ -5,7 +5,7 @@ This page is designed to help you use logs to troubleshoot issues with your Kube
 
 ## Logging by Kubernetes Components
 
-Kubernetes components, such as kubelet and apiserver, use the [glog](https://godoc.org/github.com/golang/glog) logging library.  Developer conventions for logging severity are described in [docs/devel/logging.md](/docs/devel/logging).
+Kubernetes components, such as kubelet and apiserver, use the [glog](https://godoc.org/github.com/golang/glog) logging library.  Developer conventions for logging severity are described in [docs/devel/logging.md](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/logging.md).
 
 ## Examining the logs of running containers
 

docs/user-guide/pod-states.md

@@ -7,7 +7,7 @@ This document covers the lifecycle of a pod.  It is not an exhaustive document,
 
 ## Pod Phase
 
-As consistent with the overall [API convention](/docs/devel/api-conventions/#typical-status-properties), phase is a simple, high-level summary of the phase of the lifecycle of a pod. It is not intended to be a comprehensive rollup of observations of container-level or even pod-level conditions or other state, nor is it intended to be a comprehensive state machine.
+As consistent with the overall [API convention](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#typical-status-properties), phase is a simple, high-level summary of the phase of the lifecycle of a pod. It is not intended to be a comprehensive rollup of observations of container-level or even pod-level conditions or other state, nor is it intended to be a comprehensive state machine.
 
 The number and meanings of `PodPhase` values are tightly guarded.  Other than what is documented here, nothing should be assumed about pods with a given `PodPhase`.
 

docs/user-guide/secrets.md

@@ -189,7 +189,7 @@ the original pod must be deleted, and a new pod (perhaps with an identical
 workflow as deploying a new container image.  The `kubectl rolling-update`
 command can be used ([man page](/docs/user-guide/kubectl/kubectl_rolling-update)).
 
-The [`resourceVersion`](/docs/devel/api-conventions/#concurrency-control-and-consistency)
+The [`resourceVersion`](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#concurrency-control-and-consistency)
 of the secret is not specified when it is referenced.
 Therefore, if a secret is updated at about the same time as pods are starting,
 then it is not defined which version of the secret will be used for the pod. It

docs/user-guide/working-with-resources.md

@@ -5,7 +5,7 @@
 and who want to learn more about using kubectl to manage resources such
 as pods and services.  Users who want to access the REST API directly,
 and developers who want to extend the Kubernetes API should
-refer to the [api conventions](/docs/devel/api-conventions) and
+refer to the [api conventions](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md) and
 the [api document](/docs/api/).*
 
 ## Resources are Automatically Modified
@@ -41,9 +41,9 @@ If you `diff -u /tmp/original.yaml /tmp/current.yaml`, you can see the fields ad
 The system adds fields in several ways:
 
   - Some fields are added synchronously with creation of the resource and some are set asynchronously.
-    - For example: `metadata.uid` is set synchronously.  (Read more about [metadata](/docs/devel/api-conventions/#metadata)).
-    - For example, `status.hostIP` is set only after the pod has been scheduled.  This often happens fast, but you may notice pods which do not have this set yet.  This is called Late Initialization.  (Read mode about [status](/docs/devel/api-conventions/#spec-and-status) and [late initialization](/docs/devel/api-conventions/#late-initialization) ).
-  - Some fields are set to default values.  Some defaults vary by cluster and some are fixed for the API at a certain version.  (Read more about [defaulting](/docs/devel/api-conventions/#defaulting)).
+    - For example: `metadata.uid` is set synchronously.  (Read more about [metadata](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#metadata)).
+    - For example, `status.hostIP` is set only after the pod has been scheduled.  This often happens fast, but you may notice pods which do not have this set yet.  This is called Late Initialization.  (Read mode about [status](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#spec-and-status) and [late initialization](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#late-initialization) ).
+  - Some fields are set to default values.  Some defaults vary by cluster and some are fixed for the API at a certain version.  (Read more about [defaulting](https://github.com/kubernetes/kubernetes/tree/{{page.githubbranch}}/docs/devel/api-conventions.md#defaulting)).
     - For example, `spec.containers[0].imagePullPolicy` always defaults to `IfNotPresent` in api v1.
     - For example, `spec.containers[0].resources.limits.cpu` may be defaulted to  `100m` on some clusters, to some other value on others, and not defaulted at all on others.