Revision History

shirleydst

In Exercise 5.4: Rolling Updates and Rollbacks, step 12 states:
In our case there are only two revisions, which is also the default number kept.

How can we override this?

Searching on "Revision History" I found
Revision History Limit - A Deployment's revision history is stored in the ReplicaSets it controls.
.spec.revisionHistoryLimit is an optional field that specifies the number of old ReplicaSets to retain to allow rollback. **
try1 has:
**revisionHistoryLimit: 10

Yet after experimenting with --record to create additional revisions, it seems that only two are kept:
$ k rollout history deployment try1
deployment.apps/try1
REVISION CHANGE-CAUSE
3
4 kubectl edit deployments.apps try1 --record=true
$ k rollout history deployment try1 --revision=1
error: unable to find the specified revision
$ k rollout history deployment try1 --revision=3
deployment.apps/try1 with revision #3
Pod Template: ....

There is an example on https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#revision-history-limit which shows 3 items of revision history.

shirleydst

Interestingly this seemed to behave differently when I worked on something else. However it still didn't behave in a consistent way.

chrispokorni

Hi @shirleydst,

Did you happen to run several consecutive rolling updates? How many of them generated revisions in the history list?

Regards,
-Chris

shirleydst

I made 4 edits to the deployment's image version and although the revision history index incremented, only two items of history were listed at any point in time.

serewicz

Hello,

Things change all the time with Kubernetes. There was a release where there were two changes kept, and now I think it's back up to 10. The current setting is revisionHistoryLimit: 10 Which can be edited or set when the deployment is created.

When you use a previous rollout of a deployment the replicaset numbering is changed. So where you may have had a "2" it gets renumbered to "6" should you go back to it after making changes 3,4, and 5. Using a tool like Helm, Spinnaker, or other release tool would provide a durable and long-term way to manage changes made to a deployment.

Regards,