ttlStrategy is missing from analysis-template and cluster-analysis-template

[a1exx-k]

Checklist:

• I've included steps to reproduce the bug.
• I've included the version of argo rollouts.

Describe the bug
As per documentation, ttlStrategy was introduced since version 1.7 - https://argo-rollouts.readthedocs.io/en/stable/features/analysis/#time-to-live-ttl-strategy.

However, it appears that ttlStrategy was added in analysisrun CRD, but was not added in analysistemplates and clusteranalysistemplates CRDs.
Because of this, we are unable to create analysisRuns with ttlStrategy .

To Reproduce

• attempt to create analysistemplates or clusteranalysistemplates with ttlStrategy defined.

Expected behavior

• analysistemplates and clusteranalysistemplates CRDs to support ttlStrategy.

Version
1.7.2

---

Message from the maintainers:

Impacted by this bug? Give it a 👍. We prioritize the issues with the most 👍.

[zachaller]

This was by design AnalysisRuns created via Argo Rollouts are TTL'ed and managed by Rollouts controller, this feature enables people to use the AnalysisRun CR on it's own. Here are the rules that the rollouts controller uses to TTL AR's

// 1. The analysis run has no pod hash label,
// 2. There is no ReplicaSet with the same pod hash as the analysis run
// 3. The ReplicaSet that has the same pod hash as the analysis run has a deletiontimestamp.
// Note: It is okay to use pod hash for filtering since the analysis run's pod hash is originally derived from the new RS.
// Even if there is a library change during the lifetime of the analysis run, the ReplicaSet's pod hash that the analysis
// run references does not change.

[a1exx-k]

@zachaller thx for providing the details.
I'm still unclear on how to set TTL values if we use analysisTemplates - as per your response it seems to me that these values are set by controller, however, it does not seem to be the case in practice (we run controller v1.7.2). Are there any additional flags/config needed for the controller?
It seems that adding TTL value support for analysisTemplate would not limit the use of AnalysisRuns on it's own - unless I'm missing something?

[zachaller]

They are not set, the cleanup logic is based on those rules instead of ttl's. I think those rules generally make sense for ttl'ing AnalysisRuns managed by the argo rollouts controller.

Another way of looking at it is you can use rollouts max replicasets to keep around as another way to control analysis run removal.

[a1exx-k]

I see, thanks for clarification.
Our issue is if we have background analysis that blocks the release based on 3rd-party metric (canary allowed / not allowed), then we are unable to retry the release once 3rd-party metric is back to "positive" state, without manually removing failed analysisRun.

Would the manual setting of TTLs on analysis be considered?
Ability to set TTLs on each analysis manually via template ahead of controller cleanup logic would seem beneficial and would allow for the use cases like ours, where analysis is based on external metric and not related to the build itself.

[zachaller]

Having that failed analysis there would not block a retry, you should still be able to issues a retry on the rollout and it will create a another analysis run with a -[1-9] in the name and use that for the retry.