Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release v1 versions of Task, TaskRun, Pipeline, and PipelineRun CRDs #5541

Closed
lbernick opened this issue Sep 22, 2022 · 18 comments · Fixed by #6444
Closed

Release v1 versions of Task, TaskRun, Pipeline, and PipelineRun CRDs #5541

lbernick opened this issue Sep 22, 2022 · 18 comments · Fixed by #6444
Assignees

Comments

@lbernick
Copy link
Member

This issue tracks the release of v1 api versions for Task, TaskRun, Pipeline, and PipelineRun.

Before doing this, we would like to wait for remote resolution beta (#4710), since we want to provide an alternative to taskref.bundle and pipelineref.bundle.

It would be nice to wait for custom tasks beta (#4313) so we can release v1 versions of these CRDs along with custom task beta, but there's still more work to do there and I'm not sure this should be a blocker.

Steps:

  1. Create examples tests for v1 versions of our CRDs (probably just copy pasting existing examples tests, swapping api versions, and removing any that aren't relevant for v1 such as those that test pipelineresources). This will probably require step 2 but it would be nice if there's a way to do it first. It will probably be easiest to do all the CRDs at once, but it's not necessary to do so.
  2. Update CRDs to serve v1 versions. At this point, we're "committing" to the structure of the v1 api-- no more changes.
  3. Update CRDs to use v1 as the stored version, and in the same PR, update the reconcilers to reconcile the v1 versions of the CRDs. Again, we don't have to do all the CRDs at once here, but we might find it easier to do so. One catch is that we must deserialize PipelineResources from annotations in v1 CRDs if they are present. (They may have been created by conversion from v1beta1 CRDs referencing PipelineResources.) Failing to support PipelineResources in this way would be violating our compatibility policy by not supporting a v1beta1 feature for 9 months following the v1 release. After completing step 3, we'll be able to add new features in v1 and should stop making any changes to v1beta1.
@lbernick
Copy link
Member Author

@tektoncd/core-maintainers since remote resolution beta is in our 0.41.0 milestone, I think we should start work on this rather than blocking on the remaining work that needs to be done for custom tasks beta. It would be nice to release them all at once, but I don't see any reason why these CRDs in v1 wouldn't work with v1alpha1 Runs for the time being. Thoughts?

@lbernick
Copy link
Member Author

Discussed in today's api wg: folks seem to be OK with going forward with this plan without blocking on custom tasks beta but would like to block on remote resolution beta. We should review our plan for supporting deprecated fields (#4546) before swapping our stored versions over to v1.

@JeromeJu
Copy link
Member

JeromeJu commented Nov 21, 2022

Would like to confirm the understanding on the part iii.

Basically what is needed here is changing most v1beta1 to v1 in reconcilers and regarding directories. While for the deprecated fields, I am referring to the previous v1alpha1 to v1beta1 changes and in the example of deprecated resources for taskRun for v1, I would need to check tr.ObjectMeta.Annotations contains resources and if so reusing the v1beta1 reconciling codes while marking it as deprecated in comments?

@lbernick
Copy link
Member Author

Yes, that sounds right to me!

@JeromeJu
Copy link
Member

JeromeJu commented Jan 10, 2023

Deprecated features that needs to be handled as part of the storage version migration:

The followings are not blockers of the v1 storage swap:

@lbernick
Copy link
Member Author

I don't think addressing issues like #5964 is a blocker for swapping the storage version to v1. It seems like #5979 and #5967 are the only blockers?

@JeromeJu
Copy link
Member

JeromeJu commented Mar 27, 2023

I don't think addressing issues like #5964 is a blocker for swapping the storage version to v1.

If that makes sense, my understanding is instead of addressing issues like #5964 , the round-trip conversion test is to prevent such issue from happening.

It seems like #5979 and #5967 are the only blockers?

Yes, I agree. But I think #5979 is going to be handled within the same PR of the storage swap since I could not figure out a way to separately isolate the TaskObject interface.

@lbernick
Copy link
Member Author

Would you mind updating #5979 with the details of what you tried?

@JeromeJu
Copy link
Member

JeromeJu commented Mar 28, 2023

Thanks to the guidance and talked offline with @vdemeester , the following would also be blockers/ bugs for v1 storage version change:

@JeromeJu
Copy link
Member

JeromeJu commented Apr 4, 2023

Aligned in WG @4 April that we are going to delay to v0.48, which is after the earliest LTS v0.47 to minimize impacts on LTS users while we are going to merge v1 storage swap soon as possible in early v0.48 to get enough window for fixing for v0.48.

@pritidesai pritidesai added this to the Pipelines v0.48 milestone Apr 4, 2023
JeromeJu added a commit to JeromeJu/pipeline that referenced this issue Apr 5, 2023
This commit makes the conversions required for reconciling the deprecated
v1beta1 CustomTask public in the apis.

part of tektoncd#5541
JeromeJu added a commit to JeromeJu/pipeline that referenced this issue Apr 5, 2023
This commit makes the conversions required for reconciling the deprecated
v1beta1 CustomTask exported in the apis.

part of tektoncd#5541
@JeromeJu
Copy link
Member

JeromeJu commented Apr 5, 2023

JeromeJu added a commit to JeromeJu/pipeline that referenced this issue Apr 5, 2023
This commit exports the conversions required for reconciling the deprecated
v1beta1 CustomRun in the apis.

part of tektoncd#5541
@JeromeJu
Copy link
Member

JeromeJu commented Apr 27, 2023

This is to update the current blockers:

@dibyom
Copy link
Member

dibyom commented May 2, 2023

@pritidesai
Copy link
Member

Pipelines WG - this is at risk, blocked by an issue #6616

@chuangw6
Copy link
Member

Pipelines WG - this is at risk, blocked by an issue #6616

Seems like it's less possible to include this in v0.48. Should we move it to next release?

@chuangw6
Copy link
Member

cc @jerop

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Status: Done
Development

Successfully merging a pull request may close this issue.

6 participants