Include a default Revision History Limit to avoid keeping old RCs / RSs
See original GitHub issueBy default if no Revision History Limit is added to DeploymentConfigs or Deployments spec then all old ReplicationControllers / ReplicaSets will be kept. This consumes resources in etcd and crowding the output of kubectl get rs
/ oc get rc
source https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#revision-history-limit
Should we add a default value when generating DC / deployment yaml?
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:13 (13 by maintainers)
Top Results From Across the Web
Version Control Systems | A Technical Guide to VCS Internals
Learn what a version control system is and provide technical details of some of the most popular version control systems like SCCS, RCS, ......
Read more >linux - Keep a history of all the modifications to a text file
I use locked mode for files that I'm actively modifying, but when I want to keep a revision history of the contents.
Read more >Ensure Rollout has revision history set | Datree docs
revisionHistoryLimit is an optional field that specifies the number of old ReplicaSets to retain to allow rollback. These old ReplicaSets consume resources ...
Read more >BackupPC Documentation
Add some margin in case you add more machines or decide to keep more old ... version the configure.pl script will keep the...
Read more >Git for Subversion users - Command Line Fanatic
The job of the version control system is to keep track of all of the ... that you have a server configured (which...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
so it’d go in this package https://github.com/fabric8io/fabric8-maven-plugin/tree/master/enricher/standard/src/main/java/io/fabric8/maven/enricher/standard then be in this file https://github.com/fabric8io/fabric8-maven-plugin/blob/master/enricher/standard/src/main/resources/META-INF/fabric8/enricher-default
I guess this would be
standard
enricher; as its standard stuff and not related to whether fabric8 CI / CD was being used