Configure deployments to have no own revisionHistoryLimit

The revision history limit of a deployment are its replicasets. As Knative has its own concept of revisions and the way a deployment looks like for revision is defined by the revision, there is no reason to maintain a history of replicasets. Multiple replicasets can exist if Knative configuration is updated (config-deployment) or if Knative itself is updated (and the queue-proxy image changes). Having no revisionHistoryLimit on the Deployment saves a lot of space in the Kubernetes database.

Signed-off-by: Sascha Schwarze <schwarzs@de.ibm.com>

Author: SaschaSchwarze0

pkg/reconciler/revision/resources/deploy.go

@@ -388,6 +388,7 @@ func MakeDeployment(rev *v1.Revision, cfg *config.Config) (*appsv1.Deployment, e
 			Replicas:                ptr.Int32(replicaCount),
 			Selector:                makeSelector(rev),
 			ProgressDeadlineSeconds: ptr.Int32(progressDeadline),
+			RevisionHistoryLimit:    ptr.Int32(0),
 			Strategy: appsv1.DeploymentStrategy{
 				Type: appsv1.RollingUpdateDeploymentStrategyType,
 				RollingUpdate: &appsv1.RollingUpdateDeployment{

pkg/reconciler/revision/resources/deploy_test.go

@@ -202,7 +202,7 @@ var (
 	}
 
 	defaultPodSpec = &corev1.PodSpec{
-		TerminationGracePeriodSeconds: refInt64(45),
+		TerminationGracePeriodSeconds: ptr.Int64(45),
 		EnableServiceLinks:            ptr.Bool(false),
 	}
 
@@ -259,6 +259,7 @@ var (
 				},
 			},
 			ProgressDeadlineSeconds: ptr.Int32(0),
+			RevisionHistoryLimit:    ptr.Int32(0),
 			Strategy: appsv1.DeploymentStrategy{
 				Type: appsv1.RollingUpdateDeploymentStrategyType,
 				RollingUpdate: &appsv1.RollingUpdateDeployment{
@@ -310,10 +311,6 @@ func defaultRevision() *v1.Revision {
 	}
 }
 
-func refInt64(num int64) *int64 {
-	return &num
-}
-
 type (
 	containerOption  func(*corev1.Container)
 	podSpecOption    func(*corev1.PodSpec)