Merge pull request #13297 from piosz/initial-proposal

docs/proposals/initial-resources.md

@@ -39,7 +39,7 @@ and set them before the container is run. This document describes design of the
 ## Motivation
 
 Since we want to make Kubernetes as simple as possible for its users we don’t want to require setting
-[Resources](https://github.com/GoogleCloudPlatform/kubernetes/blob/7c9bbef96ed7f2a192a1318aa312919b861aee00/pkg/api/v1/types.go#L696)
+[Resources](resource-qos.md#resource-specifications)
 for container by its owner. On the other hand having Resources filled is critical for scheduling decisions.
 Current solution to set up Resources to hardcoded value has obvious drawbacks. We need to implement a component
 which will set initial Resources to a reasonable value.
@@ -47,12 +47,12 @@ which will set initial Resources to a reasonable value.
 ## Design
 
 InitialResources component will be implemented as an [admission plugin](../../plugin/pkg/admission/) and invoked right before
-[LimitRanger](https://github.com/GoogleCloudPlatform/kubernetes/blob/7c9bbef96ed7f2a192a1318aa312919b861aee00/cluster/gce/config-default.sh#L91).
+[LimitRanger](https://github.com/kubernetes/kubernetes/blob/7c9bbef96ed7f2a192a1318aa312919b861aee00/cluster/gce/config-default.sh#L91).
 For every container without Resources specified it will try to predict amount of resources that should be sufficient for it.
 So that a pod without specified resources will be treated as
-[Burstable](https://github.com/GoogleCloudPlatform/kubernetes/blob/be5e224a0f1c928d49c48aa6a6539d22c47f9238/docs/proposals/resource-qos.md#qos-classes).
+[Burstable](resource-qos.md#qos-classes).
 
-InitialResources will set only [Request](https://github.com/GoogleCloudPlatform/kubernetes/blob/3d2d99c6fd920386eea4ec050164839ec6db38f0/pkg/api/v1/types.go#L665)
+InitialResources will set only [request](resource-qos.md#resource-specifications)
 (independently for each resource type: cpu, memory)
 field in the first version to avoid killing containers due to OOM (however the container still may be killed if exceeds requested resources).
 To make the component work with LimitRanger the estimated value will be capped by min and max possible values if defined.
@@ -60,7 +60,7 @@ It will prevent from situation when the pod is rejected due to too low or too hi
 
 The container won’t be marked as managed by this component in any way, however appropriate event will be exported.
 The predicting algorithm should have very low latency to not increase significantly e2e pod startup latency
-[#3954](https://github.com/GoogleCloudPlatform/kubernetes/pull/3954).
+[#3954](https://github.com/kubernetes/kubernetes/pull/3954).
 
 ### Predicting algorithm details