-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Towards v1 API #3548
Comments
I would like to see #3440 in v1 - and deprecate the current place were I also think #3551 would be nice to do / try out before v1. Replace the Affinity Assistant with a Custom Scheduler #3052 would also be nice - even though not strictly an API-thing, but before 1.0. Personally I would prefer the current constraints since I, as default expect 1) that declared parallel tasks can execute in parallel - with PVC, 2) that pipelineruns can not deadlock depending on how I use PVCs |
I think that making some changes to the constraints the affinity assistant imposes before v1 would make a lot of sense - for example I really don't like it that (unless im understanding incorrectly) trying to use 2 PVCs with 1 Task right now will not be allowed (unless you disable the affinity assistant). Even if we keep that, I think it shouldn't be the default. |
@bobcatfish I opened #3563 for discussion |
@vdemeester maybe we can triage #3163 and potentially have it as part of our v1 roadmap? |
Except in " Migration path from v1beta1 to v1 " I don't see how it affects the |
I think it's part of the migration path @vdemeester - when we add v1, we'll have another API type to worry about having end to end tests for |
@vdemeester possible item to triage: have we discussed at all revisiting the structure of the |
We can definitely discuss that :) |
Another item to add to our list (from our governing board meeting):
|
@vdemeester we missed you in the API meeting on Monday where we discussed adding #3792 to the V1 work here, what do you think? |
We should definitely add it to the list of things to discuss and work on yes 😉 |
Another item to add to our list - I think @sbwsg 's comment touches on this - but we have a bunch of feature flags we can probably remove (i.e. set the behavior they guard as the default): https://github.com/tektoncd/pipeline/blob/master/docs/install.md#customizing-the-pipelines-controller-behavior (maybe these are just the creds related flags?) |
The following comment is written in another issue #4048 because I thought this should be published as a new issue.
|
another thing to think about adding ... or removing that is XD: volumes + volume mounts (do these provide anything we need in addition to workspaces?) #2058 |
@kobaji I don't think we have any firm dates but are hoping for early 2022 (lemme know if you have different thoughts @vdemeester @afrittoli ) |
Right, so on this, I am going to open an issue that is slightly related, on volume, workspace, configmap and secrets.
Yeah that's more or less what I have in mind. And again, this is for a |
#4055 ^^ |
Thank you @bobcatfish , @vdemeester for your kindness. |
This change is a clarification and update to the migration and upgrade plan for skipping strategies. The implementable proposal is to change the scope of `when` expressions to guard the `Task`. This is a backwards-incompatible change. To make the transition smooth, we plan to: - provide a feature flag, `scope-when-expressions-to-task`, which: - will default to `scope-when-expressions-to-task` : "false" to guard a `Task` and its dependent `Tasks` - can be set to `scope-when-expressions-to-task` : "true" to guard a `Task` only - after 9 months, per the [Tekton API compatibility policy](https://github.com/tektoncd/pipeline/blob/main/api_compatibility_policy.md#alpha-beta-and-ga), we'll flip the feature flag and default to ` scope-when-expressions-to-task` : "true" [February 2022] - in the next release, we'll remove the feature flag and `when` expressions will be scoped to guard a `Task` only going forward [March 2022] - when we do [v1 release](tektoncd/pipeline#3548) (projected for early 2022), we will have `when` expressions guarding a `Task` only both in _beta_ and _v1_ We also plan to over-communicate during the migration in Slack, email and working group meetings.
This change is a clarification and update to the migration and upgrade plan for skipping strategies. The implementable proposal is to change the scope of `when` expressions to guard the `Task`. This is a backwards-incompatible change. To make the transition smooth, we plan to: - provide a feature flag, `scope-when-expressions-to-task`, which: - will default to `scope-when-expressions-to-task` : "false" to guard a `Task` and its dependent `Tasks` - can be set to `scope-when-expressions-to-task` : "true" to guard a `Task` only - after 9 months, per the [Tekton API compatibility policy](https://github.com/tektoncd/pipeline/blob/main/api_compatibility_policy.md#alpha-beta-and-ga), we'll flip the feature flag and default to ` scope-when-expressions-to-task` : "true" [February 2022] - in the next release, we'll remove the feature flag and `when` expressions will be scoped to guard a `Task` only going forward [March 2022] - when we do [v1 release](tektoncd/pipeline#3548) (projected for early 2022), we will have `when` expressions guarding a `Task` only both in _beta_ and _v1_ We also plan to over-communicate during the migration in Slack, email and working group meetings.
This change is a clarification and update to the migration and upgrade plan for skipping strategies. The implementable proposal is to change the scope of `when` expressions to guard the `Task`. This is a backwards-incompatible change. To make the transition smooth, we plan to: - provide a feature flag, `scope-when-expressions-to-task`, which: - will default to `scope-when-expressions-to-task` : "false" to guard a `Task` and its dependent `Tasks` - can be set to `scope-when-expressions-to-task` : "true" to guard a `Task` only - after 9 months, per the [Tekton API compatibility policy](https://github.com/tektoncd/pipeline/blob/main/api_compatibility_policy.md#alpha-beta-and-ga), we'll flip the feature flag and default to ` scope-when-expressions-to-task` : "true" [February 2022] - in the next release, we'll remove the feature flag and `when` expressions will be scoped to guard a `Task` only going forward [March 2022] - when we do [v1 release](tektoncd/pipeline#3548) (projected for early 2022), we will have `when` expressions guarding a `Task` only both in _beta_ and _v1_ We also plan to over-communicate during the migration in Slack, email and working group meetings.
Hey folks - I seem to recall a while back in API WG discussion around possibly deprecating ClusterTasks (with possibly bundles as a replacement). Is my memory totally faulty here? I'm not seeing any reference to it here, nor am I know finding it in the design doc bookmarks I still have, nor seeing any open/closed issues with ClusterTask in the title, so perhaps my memory is faulty :-/ If not though, is that deprecation still being considered, or has it been dismissed? thanks ! |
Your memory is not faulty, and indeed even though we discussed it, we never created an issue around it (and we probably should indeed 😛 ) |
Another one i think we should add to our v1 list is to tackle #3497 - decide if we're okay with the current functionality going forward or not. |
consider if we need to tackle #4399 before v1 |
Created #4476 for discussion around |
@jerop how do we want to maintain this compared/with https://github.com/orgs/tektoncd/projects/10 and the V1 TEP ? |
I'd prefer using the project board since it makes it easier to add/remove issues, track their status, and add commentary about each one |
@lbernick I tend to agree 😇 |
@vdemeester @lbernick agree with both of you that the project board is great for tracking items, and I'd add that the V1 TEP is useful for reaching alignment on what items are in scope before they are added to the board -- thank you @vdemeester for scoping the items in this issue, it's been so useful and strongly influenced both the TEP and project board 🙏 |
BTW, I just thought to mention here that the various Tekton Roadmaps are all still listed as "2021 Roadmaps" such as https://github.com/tektoncd/pipeline/blob/main/roadmap.md and https://github.com/tektoncd/community/blob/main/roadmap.md#2021-roadmap (there are more). |
/close using project board for tracking |
@lbernick: Closing this issue. In response to this:
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. |
Yeah we need to refine those. |
@StevenACoffman @vdemeester moved those roadmap items into a project view so that it's live: https://github.com/orgs/tektoncd/projects/16/views/15 |
This issue is here to track work towards the
v1
API oftektoncd/pipeline
. It is loosely based on the initial doc around this, and will be update as we go.Motivation
In order to declare Pipeline stable and ready to use in production
to our users and customer, we need to give them some
guarantees. Although
v1beta1
has some guarantees, most users arewaiting for a
v1
API set that they can rely on for the long term.If we can, in addition, come with a set of rules that would help us
decide when a feature request should be considered as required or not
for a
v1
API, this would be nice 🙃.Identified work
v1beta1
tov1
@vdemeesterNice to have
To triage
Use stories (to cover)
We should come with a bunch of user stories (from actual users) to highlight the requirements.
See also here 😅
/area epic
/area roadmap
/kind feature
/assign
/cc @tektoncd/core-maintainers
The text was updated successfully, but these errors were encountered: