Fix links after design proposal move

contributors/design-proposals/api-machinery/apiserver-build-in-admission-plugins.md

@@ -4,7 +4,7 @@
 
 | Topic | Link |
 | ----- | ---- |
-| Admission Control | https://github.com/kubernetes/community/blob/master/contributors/design-proposals/admission_control.md |
+| Admission Control | https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/admission_control.md |
 
 ## Introduction
 

contributors/design-proposals/api-machinery/dynamic-admission-control-configuration.md

@@ -2,13 +2,13 @@
 ## Background
 
 The extensible admission control
-[proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/admission_control_extension.md)
+[proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/admission_control_extension.md)
 proposed making admission control extensible. In the proposal, the `initializer
 admission controller` and the `generic webhook admission controller` are the two
 controllers that set default initializers and external admission hooks for
 resources newly created. These two admission controllers are in the same binary
 as the apiserver. This
-[section](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/admission_control_extension.md#dynamic-configuration)
+[section](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/admission_control_extension.md#dynamic-configuration)
 gave a preliminary design of the dynamic configuration of the list of the
 default admission controls. This document hashes out the implementation details.
 

contributors/design-proposals/auth/pod-security-policy.md

@@ -18,7 +18,7 @@ granting the user themselves an elevated set of permissions.
 
 ## Goals
 
-1.  Associate [service accounts](../design-proposals/service_accounts.md), groups, and users with
+1.  Associate [service accounts](service_accounts.md), groups, and users with
 a set of constraints that dictate how a security context is established for a pod and the pod's containers.
 1.  Provide the ability for users and infrastructure components to run pods with elevated privileges
 on behalf of another user or within a namespace where privileges are more restrictive.

contributors/design-proposals/cloud-provider/cloudprovider-storage-metrics.md

@@ -29,7 +29,7 @@ but we only focus on storage API calls here.
 ### Metric format and collection
 
 Metrics emitted from cloud provider will fall under category of service metrics
-as defined in [Kubernetes Monitoring Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/monitoring_architecture.md).
+as defined in [Kubernetes Monitoring Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md).
 
 
 The metrics will be emitted using [Prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/) and available for collection
@@ -40,7 +40,7 @@ metrics on `/metrics` HTTP endpoint. This proposal merely extends available metr
 Any collector which can parse Prometheus metric format should be able to collect
 metrics from these endpoints.
 
-A more detailed description of monitoring pipeline can be found in [Monitoring architecture] (https://github.com/kubernetes/community/blob/master/contributors/design-proposals/monitoring_architecture.md#monitoring-pipeline) document.
+A more detailed description of monitoring pipeline can be found in [Monitoring architecture] (https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md#monitoring-pipeline) document.
 
 
 #### Metric Types

contributors/design-proposals/instrumentation/core-metrics-pipeline.md

@@ -32,20 +32,20 @@ This document proposes a design for the set of metrics included in an eventual C
 ["cAdvisor":](https://github.com/google/cadvisor) An open source container monitoring solution which only monitors containers, and has no concept of kubernetes constructs like pods or volumes.  
 ["Summary API":](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/stats/v1alpha1/types.go) A kubelet API which currently exposes node metrics for use by both system components and monitoring systems.  
 ["CRI":](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md) The Container Runtime Interface designed to provide an abstraction over runtimes (docker, rkt, etc).  
-"Core Metrics": A set of metrics described in the [Monitoring Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/monitoring_architecture.md) whose purpose is to provide metrics for first-class resource isolation and untilization features, including [resource feasibility checking](https://github.com/eBay/Kubernetes/blob/master/docs/design/resources.md#the-resource-model) and node resource management.  
+"Core Metrics": A set of metrics described in the [Monitoring Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md) whose purpose is to provide metrics for first-class resource isolation and untilization features, including [resource feasibility checking](https://github.com/eBay/Kubernetes/blob/master/docs/design/resources.md#the-resource-model) and node resource management.
 "Resource": A consumable element of a node (e.g. memory, disk space, CPU time, etc).  
 "First-class Resource": A resource critical for scheduling, whose requests and limits can be (or soon will be) set via the Pod/Container Spec.  
 "Metric": A measure of consumption of a Resource.  
 
 ### Background
-The [Monitoring Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/monitoring_architecture.md) proposal contains a blueprint for a set of metrics referred to as "Core Metrics".  The purpose of this proposal is to specify what those metrics are, to enable work relating to the collection, by the kubelet, of the metrics.
+The [Monitoring Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md) proposal contains a blueprint for a set of metrics referred to as "Core Metrics".  The purpose of this proposal is to specify what those metrics are, to enable work relating to the collection, by the kubelet, of the metrics.
 
 Kubernetes vendors cAdvisor into its codebase, and the kubelet uses cAdvisor as a library that enables it to collect metrics on containers.  The kubelet can then combine container-level metrics from cAdvisor with the kubelet's knowledge of kubernetes constructs (e.g. pods) to produce the kubelet Summary statistics, which provides metrics for use by the kubelet, or by users through the [Summary API](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/stats/v1alpha1/types.go).  cAdvisor works by collecting metrics at an interval (10 seconds, by default), and the kubelet then simply queries these cached metrics whenever it has a need for them.
 
 Currently, cAdvisor collects a large number of metrics related to system and container performance. However, only some of these metrics are consumed by the kubelet summary API, and many are not used.  The kubelet [Summary API](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/stats/v1alpha1/types.go) is published to the kubelet summary API endpoint (stats/summary).  Some of the metrics provided by the summary API are consumed by kubernetes system components, but many are included for the sole purpose of providing metrics for monitoring.
 
 ### Motivations
-The [Monitoring Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/monitoring_architecture.md) proposal explains why a separate monitoring pipeline is required.
+The [Monitoring Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md) proposal explains why a separate monitoring pipeline is required.
 
 By publishing core metrics, the kubelet is relieved of its responsibility to provide metrics for monitoring.
 The third party monitoring pipeline also is relieved of any responsibility to provide these metrics to system components.
@@ -58,7 +58,7 @@ This proposal is to use this set of core metrics, collected by the kubelet, and
 The target "Users" of this set of metrics are kubernetes components (though not necessarily directly).  This set of metrics itself is not designed to be user-facing, but is designed to be general enough to support user-facing components.
 
 ### Non Goals
-Everything covered in the [Monitoring Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/monitoring_architecture.md) design doc will not be covered in this proposal.  This includes the third party metrics pipeline, and the methods by which the metrics found in this proposal are provided to other kubernetes components.
+Everything covered in the [Monitoring Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md) design doc will not be covered in this proposal.  This includes the third party metrics pipeline, and the methods by which the metrics found in this proposal are provided to other kubernetes components.
 
 Integration with CRI will not be covered in this proposal.  In future proposals, integrating with CRI may provide a better abstraction of information required by the core metrics pipeline to collect metrics.
 
@@ -84,7 +84,7 @@ Metrics requirements for "First Class Resource Isolation and Utilization Feature
  - Kubelet
    - Node-level usage metrics for Filesystems, CPU, and Memory  
    - Pod-level usage metrics for Filesystems and Memory  
- - Metrics Server (outlined in [Monitoring Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/monitoring_architecture.md)), which exposes the [Resource Metrics API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/resource-metrics-api.md) to the following system components:
+ - Metrics Server (outlined in [Monitoring Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md)), which exposes the [Resource Metrics API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/resource-metrics-api.md) to the following system components:
    - Scheduler  
      - Node-level usage metrics for Filesystems, CPU, and Memory  
      - Pod-level usage metrics for Filesystems, CPU, and Memory  

contributors/design-proposals/instrumentation/metrics-server.md

@@ -43,7 +43,7 @@ Previously metrics server was blocked on this dependency.
 
 ### Design ###
 Metrics server will be implemented in line with
-[Kubernetes monitoring architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/monitoring_architecture.md)
+[Kubernetes monitoring architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md)
 and inspired by [Heapster](https://github.com/kubernetes/heapster).
 It will be a cluster level component which periodically scrapes metrics from all Kubernetes nodes
 served by Kubelet through Summary API. Then metrics will be aggregated, 

contributors/design-proposals/storage/volume-metrics.md

@@ -17,7 +17,7 @@ higher than individual volume plugins.
 ### Metric format and collection
 
 Volume metrics emitted will fall under category of service metrics
-as defined in [Kubernetes Monitoring Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/monitoring_architecture.md).
+as defined in [Kubernetes Monitoring Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md).
 
 
 The metrics will be emitted using [Prometheus format](https://prometheus.io/docs/instrumenting/exposition_formats/) and available for collection
@@ -27,7 +27,7 @@ from `/metrics` HTTP endpoint of kubelet and controller-manager.
 Any collector which can parse Prometheus metric format should be able to collect
 metrics from these endpoints.
 
-A more detailed description of monitoring pipeline can be found in [Monitoring architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/monitoring_architecture.md#monitoring-pipeline) document.
+A more detailed description of monitoring pipeline can be found in [Monitoring architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md#monitoring-pipeline) document.
 
 ### Metric Types
 

contributors/devel/README.md

@@ -77,7 +77,7 @@ Guide](http://kubernetes.io/docs/admin/).
   Authorization applies to all HTTP requests on the main apiserver port.
   This doc explains the available authorization implementations.
 
-* **Admission Control Plugins** ([admission_control](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/admission_control.md))
+* **Admission Control Plugins** ([admission_control](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/admission_control.md))
 
 
 ## Building releases

contributors/devel/cri-container-stats.md

@@ -25,7 +25,7 @@ integration point.
 *See the [core metrics design
 proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/core-metrics-pipeline.md)
 for more information on metrics exposed by Kubelet, and [monitoring
-architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/monitoring_architecture.md)
+architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md)
 for the evolving monitoring pipeline in Kubernetes.*
 
 # Container Metrics