summaryrefslogtreecommitdiff
path: root/resources.md
diff options
context:
space:
mode:
authorMike Danese <mikedanese@gmail.com>2015-07-14 09:37:37 -0700
committerMike Danese <mikedanese@gmail.com>2015-07-14 10:51:10 -0700
commit53eee3533f5d877d5dbbca69f7171784dacc7fbb (patch)
tree11aada7967af1985762af4d1f3dde9b8f48c544a /resources.md
parent8e5a970d432f598962d97ecd9d6ce4b07d8f79bc (diff)
automated link fixes
Diffstat (limited to 'resources.md')
-rw-r--r--resources.md4
1 files changed, 2 insertions, 2 deletions
diff --git a/resources.md b/resources.md
index 437aac09..fb147fa5 100644
--- a/resources.md
+++ b/resources.md
@@ -13,7 +13,7 @@ certainly want the docs that go with that version.</h1>
<!-- END MUNGE: UNVERSIONED_WARNING -->
**Note: this is a design doc, which describes features that have not been completely implemented.
-User documentation of the current state is [here](../compute-resources.md). The tracking issue for
+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
cpu limits on containers (not pods) are supported. "memory" is in bytes and "cpu" is in
@@ -163,7 +163,7 @@ The following are planned future extensions to the resource model, included here
## Usage data
-Because resource usage and related metrics change continuously, need to be tracked over time (i.e., historically), can be characterized in a variety of ways, and are fairly voluminous, we will not include usage in core API objects, such as [Pods](../pods.md) and Nodes, but will provide separate APIs for accessing and managing that data. See the Appendix for possible representations of usage data, but the representation we'll use is TBD.
+Because resource usage and related metrics change continuously, need to be tracked over time (i.e., historically), can be characterized in a variety of ways, and are fairly voluminous, we will not include usage in core API objects, such as [Pods](../user-guide/pods.md) and Nodes, but will provide separate APIs for accessing and managing that data. See the Appendix for possible representations of usage data, but the representation we'll use is TBD.
Singleton values for observed and predicted future usage will rapidly prove inadequate, so we will support the following structure for extended usage information: