Consider providing a storage migration job that users can run after an upgrade.

[vaikas]

Feature request

Consider providing a tool for upgrading the stored versions on the API server for various versions.

Use case

For example, EventListener has two supported API versions, v1alpha1 and v1beta1
https://github.com/tektoncd/triggers/blob/main/config/300-eventlistener.yaml#L74
https://github.com/tektoncd/triggers/blob/main/config/300-eventlistener.yaml#L39

At any given time only one storage version is supported by the CRD configuration like above. However, if there's a cluster that started with storage v1alpha1, then v1beta1 was introduced, the cluster will have a mixed versions stored in the API server.

This is fine however, as mentioned in the #1223 we should provide a conversion webhook that means a user can request either version and the correct version is returned even if the schemas are different.

As part of the cleanups however, the previous storage versions should be upgraded so that eventually we could drop the previously supported versions (say, like v1alpha1 at some point should probably deprecated and removed?). As per:

https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#previous-storage-versions

there's a tool that users could run. However, in Knative, we decided to have tools (k8s jobs) that would at each release upgrade the necessary storage versions. Just wanted to throw this out there, since it seemed to resonate with users.

One such example is here:
knative/eventing#3168

[vdemeester]

cc @tektoncd/core-maintainers too as this would apply to tektoncd/pipeline as well (and @tektoncd/operator-maintainers for the operator 😛 )

[vaikas]

And the cool thing is that it should just be the matter of updating the list of resources that need to have their storages migrated like so:
https://github.com/knative/eventing/pull/3168/files#diff-f4f5ee556d4ac9c801a8248840b9d7bc522275086b72865457ba6074e6168d93R38

So no changes are required to add additional resources.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[dibyom]

/cc @jerop @lbernick - We'll need this if we ever plan to drop the v1alpha1 version in pipelines.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[vdemeester]

/lifecycle frozen
I think it still needs to be fixed 👼🏼