Merge branch 'master' into front-proxy

jaredbhatti · web-flow · commit cf5d62be1475 · 2016-11-21T13:59:03.000-08:00
diff --git a/_data/reference.yml b/_data/reference.yml
@@ -219,7 +219,7 @@ toc:
   - title: Replication Controller
     path: /docs/user-guide/replication-controller/    
   - title: Resource Quotas
-    path: /docs/admin/resource-quota/    
+    path: /docs/admin/resourcequota/
   - title: Scheduled Jobs
     path: /docs/user-guide/scheduled-jobs/
   - title: Secrets
@@ -269,6 +269,6 @@ toc:
   - title: Federation Components
     section:
     - title: federation-apiserver
-      path: /docs/admin/federation-apiserver.md
+      path: /docs/admin/federation-apiserver
     - title : federation-controller-mananger
-      path: /docs/admin/federation-controller-manager.md
+      path: /docs/admin/federation-controller-manager
diff --git a/docs/admin/addons.md b/docs/admin/addons.md
@@ -15,7 +15,7 @@ Add-ons in each section are sorted alphabetically - the ordering does not imply
 * [Canal](https://github.com/tigera/canal/tree/master/k8s-install/kubeadm) unites Flannel and Calico, providing networking and network policy.
 * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml) is a overlay network provider that can be used with Kubernetes.
 * [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/user-guide/networkpolicies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize).
-* [Weave Net](https://github.com/weaveworks/weave-kube) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.
+* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.
 
 ## Visualization &amp; Control
 
diff --git a/docs/user-guide/ingress.md b/docs/user-guide/ingress.md
@@ -53,18 +53,18 @@ Make sure you review the [beta limitations](https://github.com/kubernetes/contri
 A minimal Ingress might look like:
 
 ```yaml
-01. apiVersion: extensions/v1beta1
-02. kind: Ingress
-03. metadata:
-04.  name: test-ingress
-05. spec:
-06.  rules:
-07.  - http:
-08.      paths:
-09.      - path: /testpath
-10.        backend:
-11.          serviceName: test
-12.          servicePort: 80
+apiVersion: extensions/v1beta1
+kind: Ingress
+metadata:
+  name: test-ingress
+spec:
+  rules:
+  - http:
+      paths:
+      - path: /testpath
+        backend:
+          serviceName: test
+          servicePort: 80
 ```
 
 *POSTing this to the API server will have no effect if you have not configured an [Ingress controller](#ingress-controllers).*
diff --git a/docs/user-guide/production-pods.md b/docs/user-guide/production-pods.md
@@ -220,7 +220,7 @@ The specification of a pre-stop hook is similar to that of probes, but without t
 
 ## Termination message
 
-In order to achieve a reasonably high level of availability, especially for actively developed applications, it's important to debug failures quickly. Kubernetes can speed debugging by surfacing causes of fatal errors in a way that can be display using [`kubectl`](/docs/user-guide/kubectl/kubectl) or the [UI](/docs/user-guide/ui), in addition to general [log collection](/docs/user-guide/logging). It is possible to specify a `terminationMessagePath` where a container will write its 'death rattle'?, such as assertion failure messages, stack traces, exceptions, and so on. The default path is `/dev/termination-log`.
+In order to achieve a reasonably high level of availability, especially for actively developed applications, it's important to debug failures quickly. Kubernetes can speed debugging by surfacing causes of fatal errors in a way that can be display using [`kubectl`](/docs/user-guide/kubectl/) or the [UI](/docs/user-guide/ui), in addition to general [log collection](/docs/user-guide/logging). It is possible to specify a `terminationMessagePath` where a container will write its 'death rattle'?, such as assertion failure messages, stack traces, exceptions, and so on. The default path is `/dev/termination-log`.
 
 Here is a toy example:
 
