docs: add proposal for KFP component expectations and standards #11766
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: Daniel Dowler <12484302+dandawg@users.noreply.github.com>
dandawg
force-pushed
the
proposal-component-standards
branch
from
896645b to
ee23de4
Compare
|
|
||
| These issues collectively undermine the KFP user experience and hinder the growth of the KFP component ecosystem. | ||
|
|
||
| ## Proposed Solution: Define and Implement Official Component Expectations and Standards |
There was a problem hiding this comment.
Things that come to mind:
- We should mention prompt CVE fixes a must. If a component uses container images or dependencies with moderate or higher CVEs and aren't addressed within 2 months, they should be removed from the repo.
- We need clear ownership of each component. You can't just contribute it and abandon it. If the component doesn't have an owner, then it should go up for "adoption" in the KFP community. If there are no takers, it should be removed.
- A component is like an API, so there should be clear versioning.
- The minimum KFP version and SDK should be listed. It'd be cool if we defined standardize metadata around this so the SDK could fail to compile if you are using an unsupported KFP SDK or something.
There was a problem hiding this comment.
I love your suggestions on 2-4. I'll see how I can work this in.
On 1, remember that the base image is a parameter in a component, so it is meant to be changeable. The component isn't defined by a specific base image (though it's useful to have a default). Most components in the wild run on (a relatively small set of) public base images (python:3.9, pytorch/pytorch, etc.), or base images that the user swaps in. As far as standards go, we can stress using reputable/well-established images for defaults by preference. Setting specific CVE fix requirements feels too detailed for standards.
There was a problem hiding this comment.
@dandawg I think to align with your base image ideas, it'd be good if the components defaulted to a maintained base image when applicable in the event there are dependencies that are hard to install (e.g. compiles C, or requires non-Python dependencies). It could be as simple as setting a standard where the SDK builtin components are functions that return components, so it can prefill some of the component arguments like the base image.
There was a problem hiding this comment.
@mprahl I believe we're mostly on the same page, but let me know if I'm not getting something. If I understand your comment right, I think this is something already provided for in the dsl.component class. We can set the default image to a recommended generalized public image, and then users can override it if they wish (I believe this is also a plus for Python component functionality over the load yaml route).
There are some really good public images out there that precisely take care of low level stuff like GPU drivers, CUDA versions, gcc, and the like, as well as providing python dependencies (for example the deep learning images from Google).
There may be base images that we want, but that don't exist in the public space. I love the idea of figuring out how we can add support here, but I lean towards deferring this conversation until we have a specific component that we are solving for.
There was a problem hiding this comment.
My latest push some clarity around @mprahl 's points.
|
|
||
| To implement this proposal, the following steps are necessary: | ||
|
|
||
| 1. **Formalize Component Expectations:** Finalize and officially document the "Component Expectations" after giving time for community feedback and consensus. |
There was a problem hiding this comment.
I was hoping that this would be part of this KEP so that this KEP establishes the following:
- The KFP community wants clear guidelines and expectations on components.
- The KFP community agrees on what those guidelines are.
From there, it'd be fairly actionable.
There was a problem hiding this comment.
I reworded number 1 to be a little more explicit on this. Of course, this proposal itself seeks to be the starting point for the discussion.
Signed-off-by: Daniel Dowler <12484302+dandawg@users.noreply.github.com>
Description of your changes:
This PR adds a proposal to address the critical need for clear, official standards for Kubeflow Pipelines (KFP) components. The current lack of defined expectations for component structure, quality, usability, and documentation has led to inconsistencies, user confusion, and increased development burden. This proposal focuses on establishing and implementing official component expectations and standards for the KFP repository to improve the overall KFP user experience for both users and contributors.
Checklist: