From 8c06052254007660e92112f188cbcdbfb2023eac Mon Sep 17 00:00:00 2001 From: Ed Costello Date: Tue, 25 Aug 2015 10:47:58 -0400 Subject: [PATCH] Copy edits for typos (resubmitted) --- apiserver-watch.md | 4 ++-- federation.md | 6 +++--- horizontal-pod-autoscaler.md | 8 ++++---- rescheduler.md | 2 +- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/apiserver-watch.md b/apiserver-watch.md index 6bc2d33fc..b80690301 100644 --- a/apiserver-watch.md +++ b/apiserver-watch.md @@ -60,7 +60,7 @@ the objects (of a given type) without any filtering. The changes delivered from etcd will then be stored in a cache in apiserver. This cache is in fact a "rolling history window" that will support clients having some amount of latency between their list and watch calls. Thus it will have a limited capacity and -whenever a new change comes from etcd when a cache is full, othe oldest change +whenever a new change comes from etcd when a cache is full, the oldest change will be remove to make place for the new one. When a client sends a watch request to apiserver, instead of redirecting it to @@ -159,7 +159,7 @@ necessary. In such case, to avoid LIST requests coming from all watchers at the same time, we can introduce an additional etcd event type: [EtcdResync](../../pkg/storage/etcd/etcd_watcher.go#L36) - Whenever reslisting will be done to refresh the internal watch to etcd, + Whenever relisting will be done to refresh the internal watch to etcd, EtcdResync event will be send to all the watchers. It will contain the full list of all the objects the watcher is interested in (appropriately filtered) as the parameter of this watch event. diff --git a/federation.md b/federation.md index 7b642bb38..34df0aee5 100644 --- a/federation.md +++ b/federation.md @@ -518,7 +518,7 @@ thus far: approach. 1. A more monolithic architecture, where a single instance of the Kubernetes control plane itself manages a single logical cluster - composed of nodes in multiple availablity zones and cloud + composed of nodes in multiple availability zones and cloud providers. A very brief, non-exhaustive list of pro's and con's of the two @@ -563,12 +563,12 @@ prefers the Decoupled Hierarchical model for the reasons stated below). largely independently (different sets of developers, different release schedules etc). 1. **Administration complexity:** Again, I think that this could be argued - both ways. Superficially it woud seem that administration of a + both ways. Superficially it would seem that administration of a single Monolithic multi-zone cluster might be simpler by virtue of being only "one thing to manage", however in practise each of the underlying availability zones (and possibly cloud providers) has it's own capacity, pricing, hardware platforms, and possibly - bureaucratic boudaries (e.g. "our EMEA IT department manages those + bureaucratic boundaries (e.g. "our EMEA IT department manages those European clusters"). So explicitly allowing for (but not mandating) completely independent administration of each underlying Kubernetes cluster, and the Federation system itself, diff --git a/horizontal-pod-autoscaler.md b/horizontal-pod-autoscaler.md index 47a69b2d1..c10f54f78 100644 --- a/horizontal-pod-autoscaler.md +++ b/horizontal-pod-autoscaler.md @@ -56,7 +56,7 @@ We are going to introduce Scale subresource and implement horizontal autoscaling Scale subresource will be supported for replication controllers and deployments. Scale subresource will be a Virtual Resource (will not be stored in etcd as a separate object). It will be only present in API as an interface to accessing replication controller or deployment, -and the values of Scale fields will be inferred from the corresponing replication controller/deployment object. +and the values of Scale fields will be inferred from the corresponding replication controller/deployment object. HorizontalPodAutoscaler object will be bound with exactly one Scale subresource and will be autoscaling associated replication controller/deployment through it. The main advantage of such approach is that whenever we introduce another type we want to auto-scale, @@ -132,7 +132,7 @@ type HorizontalPodAutoscaler struct { // HorizontalPodAutoscalerSpec is the specification of a horizontal pod autoscaler. type HorizontalPodAutoscalerSpec struct { // ScaleRef is a reference to Scale subresource. HorizontalPodAutoscaler will learn the current - // resource consumption from its status, and will set the desired number of pods by modyfying its spec. + // resource consumption from its status, and will set the desired number of pods by modifying its spec. ScaleRef *SubresourceReference // MinCount is the lower limit for the number of pods that can be set by the autoscaler. MinCount int @@ -151,7 +151,7 @@ type HorizontalPodAutoscalerStatus struct { CurrentReplicas int // DesiredReplicas is the desired number of replicas of pods managed by this autoscaler. - // The number may be different because pod downscaling is someteimes delayed to keep the number + // The number may be different because pod downscaling is sometimes delayed to keep the number // of pods stable. DesiredReplicas int @@ -161,7 +161,7 @@ type HorizontalPodAutoscalerStatus struct { CurrentConsumption ResourceConsumption // LastScaleTimestamp is the last time the HorizontalPodAutoscaler scaled the number of pods. - // This is used by the autoscaler to controll how often the number of pods is changed. + // This is used by the autoscaler to control how often the number of pods is changed. LastScaleTimestamp *util.Time } diff --git a/rescheduler.md b/rescheduler.md index b27b9bfe4..88747d080 100644 --- a/rescheduler.md +++ b/rescheduler.md @@ -96,7 +96,7 @@ case, the nodes we move the Pods onto might have been in the system for a long t have been added by the cluster auto-scaler specifically to allow the rescheduler to rebalance utilization. -A second spreading use case is to separate antagnosits. +A second spreading use case is to separate antagonists. Sometimes the processes running in two different Pods on the same node may have unexpected antagonistic behavior towards one another. A system component might monitor for such