rewrite all links to issues to k8s links

2015-08-05 18:08:26 -07:00 · 2015-08-05 18:08:26 -07:00 · a74ffb6a38
parent a38fc06604
commit a74ffb6a38
9 changed files with 21 additions and 21 deletions
--- a/access.md
+++ b/access.md
@ -118,8 +118,8 @@ Pods configs should be largely portable between Org-run and hosted configuration
 # Design

 Related discussion:
- https://github.com/GoogleCloudPlatform/kubernetes/issues/442
- https://github.com/GoogleCloudPlatform/kubernetes/issues/443
+- http://issue.k8s.io/442
+- http://issue.k8s.io/443

 This doc describes two security profiles:
  - Simple profile:  like single-user mode.  Make it easy to evaluate K8s without lots of configuring accounts and policies.  Protects from unauthorized users, but does not partition authorized users.
@ -176,7 +176,7 @@ Initially:
 Improvements:
 - Kubelet allocates disjoint blocks of root-namespace uids for each container.  This may provide some defense-in-depth against container escapes. (https://github.com/docker/docker/pull/4572)
 - requires docker to integrate user namespace support, and deciding what getpwnam() does for these uids.
- any features that help users avoid use of privileged containers (https://github.com/GoogleCloudPlatform/kubernetes/issues/391)
+- any features that help users avoid use of privileged containers (http://issue.k8s.io/391)

 ### Namespaces

@ -253,7 +253,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 design doc](resources.md)).
+The API should have a `quota` concept (see http://issue.k8s.io/442).  A quota object relates a namespace (and optionally a label selector) to a maximum quantity of resources that may be used (see [resources design doc](resources.md)).

 Initially:
 - a `quota` object is immutable.
--- a/admission_control.md
+++ b/admission_control.md
@ -37,7 +37,7 @@ Documentation for other releases can be found at

 | Topic | Link |
 | ----- | ---- |
-| Separate validation from RESTStorage | https://github.com/GoogleCloudPlatform/kubernetes/issues/2977 |
+| Separate validation from RESTStorage | http://issue.k8s.io/2977 |

 ## Background

--- a/command_execution_port_forwarding.md
+++ b/command_execution_port_forwarding.md
@ -44,9 +44,9 @@ This describes an approach for providing support for:

 There are several related issues/PRs:

- [Support attach](https://github.com/GoogleCloudPlatform/kubernetes/issues/1521)
- [Real container ssh](https://github.com/GoogleCloudPlatform/kubernetes/issues/1513)
- [Provide easy debug network access to services](https://github.com/GoogleCloudPlatform/kubernetes/issues/1863)
+- [Support attach](http://issue.k8s.io/1521)
+- [Real container ssh](http://issue.k8s.io/1513)
+- [Provide easy debug network access to services](http://issue.k8s.io/1863)
 - [OpenShift container command execution proposal](https://github.com/openshift/origin/pull/576)

 ## Motivation
--- a/event_compression.md
+++ b/event_compression.md
@ -38,7 +38,7 @@ This document captures the design of event compression.

 ## Background

-Kubernetes components can get into a state where they generate tons of events which are identical except for the timestamp. For example, when pulling a non-existing image, Kubelet will repeatedly generate `image_not_existing` and `container_is_waiting` events until upstream components correct the image. When this happens, the spam from the repeated events makes the entire event mechanism useless. It also appears to cause memory pressure in etcd (see [#3853](https://github.com/GoogleCloudPlatform/kubernetes/issues/3853)).
+Kubernetes components can get into a state where they generate tons of events which are identical except for the timestamp. For example, when pulling a non-existing image, Kubelet will repeatedly generate `image_not_existing` and `container_is_waiting` events until upstream components correct the image. When this happens, the spam from the repeated events makes the entire event mechanism useless. It also appears to cause memory pressure in etcd (see [#3853](http://issue.k8s.io/3853)).

 ## Proposal

@ -109,10 +109,10 @@ This demonstrates what would have been 20 separate entries (indicating schedulin

 ## Related Pull Requests/Issues

- * Issue [#4073](https://github.com/GoogleCloudPlatform/kubernetes/issues/4073): Compress duplicate events
- * PR [#4157](https://github.com/GoogleCloudPlatform/kubernetes/issues/4157): Add "Update Event" to Kubernetes API
- * PR [#4206](https://github.com/GoogleCloudPlatform/kubernetes/issues/4206): Modify Event struct to allow compressing multiple recurring events in to a single event
- * PR [#4306](https://github.com/GoogleCloudPlatform/kubernetes/issues/4306): Compress recurring events in to a single event to optimize etcd storage
+ * Issue [#4073](http://issue.k8s.io/4073): Compress duplicate events
+ * PR [#4157](http://issue.k8s.io/4157): Add "Update Event" to Kubernetes API
+ * PR [#4206](http://issue.k8s.io/4206): Modify Event struct to allow compressing multiple recurring events in to a single event
+ * PR [#4306](http://issue.k8s.io/4306): Compress recurring events in to a single event to optimize etcd storage
 * PR [#4444](https://github.com/GoogleCloudPlatform/kubernetes/pull/4444): Switch events history to use LRU cache instead of map


--- a/identifiers.md
+++ b/identifiers.md
@ -33,7 +33,7 @@ Documentation for other releases can be found at

 # Identifiers and Names in Kubernetes

-A summarization of the goals and recommendations for identifiers in Kubernetes.  Described in [GitHub issue #199](https://github.com/GoogleCloudPlatform/kubernetes/issues/199).
+A summarization of the goals and recommendations for identifiers in Kubernetes.  Described in [GitHub issue #199](http://issue.k8s.io/199).


 ## Definitions
--- a/principles.md
+++ b/principles.md
@ -70,7 +70,7 @@ TODO: pluggability

 ## Bootstrapping

-* [Self-hosting](https://github.com/GoogleCloudPlatform/kubernetes/issues/246) of all components is a goal.
+* [Self-hosting](http://issue.k8s.io/246) of all components is a goal.
 * Minimize the number of dependencies, particularly those required for steady-state operation.
 * Stratify the dependencies that remain via principled layering.
 * Break any circular dependencies by converting hard dependencies to soft dependencies.
--- a/resources.md
+++ b/resources.md
@ -33,7 +33,7 @@ Documentation for other releases can be found at
 **Note: this is a design doc, which describes features that have not been completely implemented.
 User documentation of the current state is [here](../user-guide/compute-resources.md).  The tracking issue for
 implementation of this model is
-[#168](https://github.com/GoogleCloudPlatform/kubernetes/issues/168).  Currently, only memory and
+[#168](http://issue.k8s.io/168).  Currently, only memory and
 cpu limits on containers (not pods) are supported.  "memory" is in bytes and "cpu" is in
 milli-cores.**

@ -134,7 +134,7 @@ The following resource types are predefined ("reserved") by Kubernetes in the `k
  * Units: Kubernetes Compute Unit seconds/second (i.e., CPU cores normalized to a canonical "Kubernetes CPU")
  * Internal representation: milli-KCUs
  * Compressible? yes
-  * Qualities: this is a placeholder for the kind of thing that may be supported in the future &mdash; see [#147](https://github.com/GoogleCloudPlatform/kubernetes/issues/147)
+  * Qualities: this is a placeholder for the kind of thing that may be supported in the future &mdash; see [#147](http://issue.k8s.io/147)
    * [future] `schedulingLatency`: as per lmctfy
    * [future] `cpuConversionFactor`: property of a node: the speed of a CPU core on the node's processor divided by the speed of the canonical Kubernetes CPU (a floating point value; default = 1.0).

--- a/secrets.md
+++ b/secrets.md
@ -119,7 +119,7 @@ which consumes this type of secret, the Kubelet may take a number of actions:
    file system
 2.  Configure that node's `kube-proxy` to decorate HTTP requests from that pod to the
    `kubernetes-master` service with the auth token, e. g. by adding a header to the request
-    (see the [LOAS Daemon](https://github.com/GoogleCloudPlatform/kubernetes/issues/2209) proposal)
+    (see the [LOAS Daemon](http://issue.k8s.io/2209) proposal)

 #### Example: service account consumes docker registry credentials

@ -263,11 +263,11 @@ the right storage size for their installation and configuring their Kubelets cor

 Configuring each Kubelet is not the ideal story for operator experience; it is more intuitive that
 the cluster-wide storage size be readable from a central configuration store like the one proposed
-in [#1553](https://github.com/GoogleCloudPlatform/kubernetes/issues/1553).  When such a store
+in [#1553](http://issue.k8s.io/1553).  When such a store
 exists, the Kubelet could be modified to read this configuration item from the store.

 When the Kubelet is modified to advertise node resources (as proposed in
-[#4441](https://github.com/GoogleCloudPlatform/kubernetes/issues/4441)), the capacity calculation
+[#4441](http://issue.k8s.io/4441)), the capacity calculation
 for available memory should factor in the potential size of the node-level tmpfs in order to avoid
 memory overcommit on the node.

--- a/security_context.md
+++ b/security_context.md
@ -42,7 +42,7 @@ A security context is a set of constraints that are applied to a container in or

 ## Background

-The problem of securing containers in Kubernetes has come up [before](https://github.com/GoogleCloudPlatform/kubernetes/issues/398) and the potential problems with container security are [well known](http://opensource.com/business/14/7/docker-security-selinux). Although it is not possible to completely isolate Docker containers from their hosts, new features like [user namespaces](https://github.com/docker/libcontainer/pull/304) make it possible to greatly reduce the attack surface.
+The problem of securing containers in Kubernetes has come up [before](http://issue.k8s.io/398) and the potential problems with container security are [well known](http://opensource.com/business/14/7/docker-security-selinux). Although it is not possible to completely isolate Docker containers from their hosts, new features like [user namespaces](https://github.com/docker/libcontainer/pull/304) make it possible to greatly reduce the attack surface.

 ## Motivation