github/kubernetes
4
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fix confusing use of "comprise"

Browse Source 
The word "comprise" means "be composed of" or "contain" so
"applications comprised of multiple containers" would mean
"applications composed of of multiple containers" or "applications
contained of multiple containers" which is confusing.

I understand that this is nitpicking and that "comprise" has a new
meaning which is the opposite of its original definition just like
how "literally" now means "figuratively" to some people. However, I
believe that clarity is of utmost importance in technical
documentation which is why I'm proposing this change.
This commit is contained in:
Mark Maglana
2015-03-25 14:54:16 -07:00
parent 901a5dbe2b
commit fd29104ff5
5 changed files with 6 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/replication-controller.md
View File

@@ -6,7 +6,7 @@ A _replication controller_ ensures that a specified number of pod "replicas" are
As discussed in [life of a pod](pod-states.md), `replicationController` is *only* appropriate for pods with `RestartPolicy = Always`. `ReplicationController` should refuse to instantiate any pod that has a different restart policy. As discussed in [issue #503](https://github.com/GoogleCloudPlatform/kubernetes/issues/503#issuecomment-50169443), we expect other types of controllers to be added to Kubernetes to handle other types of workloads, such as build/test and batch workloads, in the future.
A replication controller will never terminate on its own, but it isn't expected to be as long-lived as services. Services may be comprised of pods controlled by multiple replication controllers, and it is expected that many replication controllers may be created and destroyed over the lifetime of a service. Both services themselves and their clients should remain oblivious to the replication controllers that maintain the pods of the services.
A replication controller will never terminate on its own, but it isn't expected to be as long-lived as services. Services may be composed of pods controlled by multiple replication controllers, and it is expected that many replication controllers may be created and destroyed over the lifetime of a service. Both services themselves and their clients should remain oblivious to the replication controllers that maintain the pods of the services.
## How does a replication controller work?