TEP-0038 "Generic Workspaces" #382
Conversation
|
/kind tep |
tekton-robot
added
kind/tep
ghost
mentioned this pull request
|
/assign @bobcatfish |
|
/assign @afrittoli |
There was a problem hiding this comment.
just a few minor comments from me - i think the problem statement makes sense, im not sure im 100% sure that im convinced it should be addressed, i.e. i think it depends on what the possible solutions are (i think im falling into the trap where im having trouble agreeing with the problem statement without knowing what the solution might look like) but anyway im happy to merge as proposed!
/approve
@afrittoli still to review:
/hold
| - A Platform Builder can't limit the set of supported volume types to only those they want to allow. | ||
| - A Platform Builder can't expand the set of supported volume types to add those they manage themselves. | ||
| - A Platform Builder can expect the set of supported Workspace types to grow as support is added | ||
| for new Kubernetes types (like `ProjectedVolume`) and must plan around those potential changes. |
There was a problem hiding this comment.
i think im being pedantic so feel free to ignore me, but im wondering if 'platform developers' are the folks who have this set of concerns, or if that's more tool developers? (i think the thing tripping me up is that im not sure why platform builders really care about systems other than the one they're building)
There was a problem hiding this comment.
(i think the thing tripping me up is that im not sure why platform builders really care about systems other than the one they're building)
My take is they care in the sense that they want to interoperate with those systems via the Tekton API. Resources from one exported and then imported to another. If the Tekton API is that locus of integration then this is the list of responsibilities that falls on the platform developer's shoulders.
Does that interpretation make sense or do you still think these concerns are first and foremost those of Tool Developers? Happy to change it if so.
There was a problem hiding this comment.
I've trimmed the list back a bit here in response to the feedback.
There was a problem hiding this comment.
kk sounds fine to me! maybe we could add tool developers as well? im thinking something like "as a tool developer I want to develop tools that will work with any k8s system" - for example the CLI can run Pipelines, but maybe it only knows about PVCs and emptyDirs as possible volumes, and doesn't know how to make a Gluster volume - id like my tool to be able to work with even systems that require Gluster volumes
(i think im just trying to polish something that's already in great shape)
There was a problem hiding this comment.
Great point - makes total sense that this is also a concern of folks writing interoperable tools. Updated!
tekton-robot
added
the
do-not-merge/hold
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bobcatfish The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
tekton-robot
added
the
approved
This TEP outlines a problem facing the Workspaces feature in Tekton Pipelines: there are many different ways that people and companies want to manage Workspaces but Tekton provides only a very narrow set of supported storage options. This was originally prposed in #290 but closed shortly after. Re-opening in response to @afrittoli's comment here: #290 (comment)
| The Pipelines API Spec is intentionally even more limited: only support for `emptyDir` is required | ||
| to conform to the v1beta1 API. All other workspace types are optional. This is done to reduce |
|
Since the hold was waiting on my review, removing it now. |
tekton-robot
removed
the
do-not-merge/hold
ghost
deleted the
This TEP outlines a problem facing the Workspaces feature in Tekton Pipelines: there are many different
ways that people and companies want to manage Workspaces but Tekton provides only a very narrow set of
supported storage options.
This was originally prposed in #290
but closed shortly after. Re-opening in response to @afrittoli 's
comment here: #290 (comment)