Removed obsolete metrics API proposal

docs/proposals/metrics-plumbing.md

@@ -94,7 +94,7 @@ Heapster stores a days worth of historical metrics. Heapster will fetch data fro
 
 To make heapster APIs compatible with Kubernetes API requirements, heapster will have to incorporate the API server library. Until that is possible, we will run a secondary API server binary that supports the metrics APIs being consumed by other components. The initial plan is to use etcd to store the most recent metrics. Eventually, we would like to get rid of etcd for metrics and make heapster act as a backend to the api-server.
 
-This is the current plan for supporting node and pod metrics API as described in this [proposal](compute-resource-metrics-api.md).
+This is the current plan for supporting node and pod metrics API as described in this [proposal](resource-metrics-api.md).
 
 There will be proposals in the future for adding more heapster metrics APIs in Kubernetes.
 

docs/proposals/node-allocatable.md

@@ -41,7 +41,7 @@ Documentation for other releases can be found at
 Currently Node.Status has Capacity, but no concept of node Allocatable. We need additional
 parameters to serve several purposes:
 
-1. [Kubernetes metrics](compute-resource-metrics-api.md) provides "/docker-daemon", "/kubelet",
+1. Kubernetes metrics provides "/docker-daemon", "/kubelet",
    "/kube-proxy", "/system" etc. raw containers for monitoring system component resource usage
    patterns and detecting regressions. Eventually we want to cap system component usage to a certain
    limit / request. However this is not currently feasible due to a variety of reasons including:

docs/proposals/resource-metrics-api.md

@@ -29,8 +29,6 @@ Documentation for other releases can be found at
 
 # Resource Metrics API
 
-*This proposal is based on and supersedes [compute-resource-metrics-api.md](compute-resource-metrics-api.md).*
-
 This document describes API part of MVP version of Resource Metrics API effort in Kubernetes.
 Once the agreement will be made the document will be extended to also cover implementation details.
 The shape of the effort may be also a subject of changes once we will have more well-defined use cases.