Feature Request: Support Multiple Revisions

[cert-manager]

Feature Request: Support Multiple Revisions

[JoshVanL]

Cool, thanks @keithmattix. I have a branch at work in the background 🙂

Will likely cover the following cases:

• Empty revision list [] -> ""
• Default in the revision list gets converted "default" -> ""
• Multiple revisions would produce ["default", "foo", "bar"] -> "", "foo", "bar"

Do we need to account for the case where the Helm revision value has both "" and "default"? This would produce a Certificate with DNS that has duplicate entries. Maybe this is fine, but can spend some time to remove duplicates in the helm template logic (😅).

[keithmattix]

You could probably just use the uniq function in Helm to filter the list before looping over it right?

[JoshVanL]

Hi @keithmattix, could you expand a bit on what you mean by revision, do you mean the revisionHistoryLimit?

[keithmattix]

Thanks for the response @JoshVanL; sorry I should've been more clear. I'm referring to Istio revisions for use with canary upgrades.

[JoshVanL]

Thanks @keithmattix, wasn't familiar of this feature with istio but is pretty cool!

Would exposing something like app.istioRevision in the helm chart make sense here?

/kind feature
/assign

[jetstack-bot]

@JoshVanL: The label(s) kind/feature cannot be applied, because the repository doesn't have them.

In response to this:

Thanks @keithmattix, wasn't familiar of this feature with istio but is pretty cool!

Would exposing something like app.istioRevision in the helm chart make sense here?

/kind feature
/assign

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[keithmattix]

Yes, I think something like that could work! It would probably need to be a list/array since one would generally have multiple revisions in a cluster during a canary upgrade. app.istioRevisions would probably suffice.