From 32aeae5684ec94df2282af57fa642bb6594a63aa Mon Sep 17 00:00:00 2001 From: Rudi Chiarito Date: Thu, 17 Mar 2016 12:04:04 -0400 Subject: [PATCH] Document revisionHistoryLimit in Deployment spec I'm not sure the field should be optional, but that ship has already sailed. It should definitely be a lot more prominent than hidden in the API docs, though. --- docs/user-guide/deployments.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/user-guide/deployments.md b/docs/user-guide/deployments.md index a76dbff5e7..38a417e198 100644 --- a/docs/user-guide/deployments.md +++ b/docs/user-guide/deployments.md @@ -558,7 +558,7 @@ To learn more about when a Pod is considered ready, see [Container Probes](/docs ### Revision History Limit -`.spec.revisionHistoryLimit` is an optional field that specifies the number of old Replica Sets to retain to allow rollback. All old Replica Sets will be kept by default, if this field is not set. The configuration of each Deployment revision is stored in its Replica Sets; therefore, once an old Replica Set is deleted, you lose the ability to rollback to that revision of Deployment. +`.spec.revisionHistoryLimit` is an optional field that specifies the number of old Replica Sets to retain to allow rollback. Its ideal value depends on the frequency and stability of new deployments. All old Replica Sets will be kept by default, consuming resources in `etcd` and crowding the output of `kubectl get rs`, if this field is not set. The configuration of each Deployment revision is stored in its Replica Sets; therefore, once an old Replica Set is deleted, you lose the ability to rollback to that revision of Deployment. More specifically, setting this field to zero means that a new deployment revision can be undone only while still in progress. ### Paused