Support RevisionHistoryLimit in Deployment and Daemonset for Elastic Agents

[knechtionscoding]

Proposal

As part of the agents.agent.k8s.elastic.co CRD under both deployment and daemonset RevisionHistoryLimit should be supported.

Deployment already supports replicas, podTemplate so adding a revisionHistoryLimit seems like a small lift.

Use case. Why is this important?

Being able to limit the number of revisionHistoryLimit matters for performance purposes, and cleaning up old replicasets, etc.

[thbkrkr]

It seems legit. Out of curiosity, could you share what kind of performance issues you are having and what value you want to set? I think by default it's set to 10.

[knechtionscoding]

I mostly want it set to something like 3.

We have lots of objects in our cluster, so we try to limit the amount of extraneous things that are stored in etcd.

Especially when they don't really serve a function past the last 1 or 2. We don't roll back, we only roll forward, so they serve little function for us.

And it makes a better user experience when viewing objects created by the deployment, via kubectl or something like argo.

[knechtionscoding]

@thbkrkr Submitted the start of a PR: #5790 It's my first time in this code so I'm not 100% sure I got everything.

[knechtionscoding]

@thbkrkr Does/would it make sense to add this for the other kinds ECK supports? i.e. elasticsearch and kibana? Happy to submit PRs for those as well and a new issue

[thbkrkr]

@thbkrkr Does/would it make sense to add this for the other kinds ECK supports? i.e. elasticsearch and kibana? Happy to submit PRs for those as well and a new issue

I don't see a good reason not to do the same for other resources managed by ECK, so yes go for it.

[knechtionscoding]

@thbkrkr Should I add support for them in both api versions where they exist? i.e. both v1 and v1beta1 for APM? Or just the latest version?

[thbkrkr]

Changing the latest version is enough.