pipeline
pipeline copied to clipboard
tektoncd
Updating pipelineTask spec to accomodate for CustomRun and Run
Feature request
As mentioned in TEP-0114, we aim to transition
v1alpa1.Run to v1beta1.Custom. After a lot of discussion regarding implementation for this feature,
some of which can be found in this PR, the team is
moving forward adding the CustomRun CRD and deprecating v1alpha1.Run after some time.
This will be done by adding a field, runAPIVersion, in the taskRef spec to distinguish which run
is being used. If the field is populated with v1alpha1 then the Run CRD will be used, and on the other hand if
v1beta1 is used, then the CustomRun CRD will be used.
Things that will need updating:
taskRefstruct- pipelineRun reconciler
- tests and adding end-to-end tests for
CustomRun
PipelineTask's TaskRef already has an APIVersion field - why do you need a new one?
The existing apiVersion filed refers to the apiversion of the custom task to use. We also need to know which version of Run or CustomRun to create. If we always create a CustomRun, users cannot use any custom tasks that only support Run. If we always create Run, users cannot use any custom tasks that have been upgraded to use CustomRuns. With a field that allows setting the apiVersion of the Run/CustomRun to be created - a user can use custom tasks that use the older v1alpha1 Run as well as tasks that use CustomRun
Aaaaaah - good point. I forgot that apiVersion specifically is referring to the "task" version, not the "run" version. 🤦
two downsides - 1. we are adding a custom task specific field into task ref and 2. having two apiVersions within the same taskRef is going to be confusing - open to other ideas here as well!
Can we write an example of usage here to see how it would look like ?
I am not sure if I completely follow the reasoning here, and I "fear" we are adding fields and complexifying things for very little gain. We also need to take into account that this is for an alpha API (both in its "usage" and its definition) — and with alpha api, we can pretty much.. switch on/off from one release to the other (if we communicate and announc it properly), so changing as well.
The problem we "are" facing here is that, the day we introduce (and use) v1beta1.CustomRun, some Custom Task may/will not work, because they only watch v1alpha1.Run objects. Do we agree on this ?
If I understand correctly, what is proposed here, is to let the user choose which object to use, which I feel is not the best user experience, nor a long-term solution. We are basically doing this for a couple of release and them removing it, right ? We are basically asking the users to set the correct "internal" object (and version) for a given time.
In my opinion, what we need to do, is to give a bit of time for Custom Task to support v1beta1.CustomRun objects. Let's take a "foo" custom task, that I am the owner. Let's also assume, for this example, that v1beta1.CustomRun is introduced and used in 0.42. With that Custom Task, I want to support multiple versions of Tekton Pipeline, let's say from v0.35.x to v0.42.x (and above). For me to support those versions, I need to be able to reconcile v1alpha1.Run and v1beta1.CustomRun, for a time being. And when I do not want to support Tekton Pipeline version below v0.42.x, I can just drop the v1alpha1.Run support.
I do not really see what we are asking the user to specify something, where it can be transparent for them. Of course, this means, all custom task "provider" will need to add support for v1beta1.CustomRun in a timely fashion (before v0.42.0) if they want to still work when this gets released. But I would rather put the burden of this transition on Custom Task authors than on pipeline's users.
This is very similar to what we face from time to time in our consumption of kubernetes APIs — e.g. autoscaling/v2beta1 HorizontalPodAutoscaler or PodSecurityPolicy that got deprecated in vX and remove in vY (possibly making tekton pipeline not work on given versions of k8s).
If I understand correctly, what is proposed here, is to let the user choose which object to use, which I feel is not the best user experience, nor a long-term solution. We are basically doing this for a couple of release and them removing it, right ? We are basically asking the users to set the correct "internal" object (and version) for a given time.
I think we can just set defaults here right? We default to v1alpha1.Run for x releases and then switch to v1beta1.CustomRun after. In case a user wants to use a custom task that has not upgraded to supporting v1beta1.CustomRun, they still have some way of using it.
I do not really see what we are asking the user to specify something, where it can be transparent for them. Of course, this means, all custom task "provider" will need to add support for v1beta1.CustomRun in a timely fashion (before v0.42.0) if they want to still work when this gets released. But I would rather put the burden of this transition on Custom Task authors than on pipeline's users.
I think this is a valid approach though I am unsure how realistic it is to expect all custom tasks to be upgraded to support both v1alpha1 Run and v1beta1 CustomRun. In any case, I think it is useful for the pipeline user to have the option to use a custom task that only supports v1alpha1 Run
I think we can just set defaults here right? We default to v1alpha1.Run for x releases and then switch to v1beta1.CustomRun after. In case a user wants to use a custom task that has not upgraded to supporting v1beta1.CustomRun, they still have some way of using it.
Yes, that would be a valid approach imho.
I think this is a valid approach though I am unsure how realistic it is to expect all custom tasks to be upgraded to support both v1alpha1 Run and v1beta1 CustomRun. In any case, I think it is useful for the pipeline user to have the option to use a custom task that only supports v1alpha1 Run
Indeed. Also, I am not sure how much Custom Task there is in the wild, but they depend on alpha api, it's in the contract that things might break 🙃