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

[feature] Option to disable Caching in V2 at the KFP, Pipeline, and Run level #10839

Open
HumairAK opened this issue May 22, 2024 · 6 comments
Open

Comments

@HumairAK
Copy link
Contributor

HumairAK commented May 22, 2024

Feature Area

/area frontend
/area backend

What feature would you like to see?

Allow flexibility in being able to enable/disable caching at multiple levels in KFP.
A user should be able to:

  • Disable caching for a single run of a pipeline
  • Disable caching for all runs for a pipeline (toggle?)
  • Disable caching entirely for a KFP deployment

The user should be able to do this VIA the UI, or API. I don't think this requires changes from SDK side, but if it does, we should point that out.

As part of this acceptance criteria, the implementer should also update the configurations to clearly indicate where the old v1 caching behavior is for v1 only and not for v2. Example here.

What is the use case or pain point?

Currently the only way to disable caching in KFP V2 is via the SDK , by setting .set_caching_options.

This can be annoying to do for every single step, every single time. In some cases a user may not be satisfied with the current caching capabilities and want to opt to not use it, the user should be easily enabled to do so.

This feature seems like it used to exist with kfp v1 cache server to some degree, but no longer exists in kfpv2.

Is there a workaround currently?

The only workaround is to disable caching via sdk on a per component basis.


Love this idea? Give it a 👍.

@HumairAK
Copy link
Contributor Author

It looks like there was a lot of work on this done by @TobiasGoerke in the past here: #8177

It seems like it didn't end up getting merged, but could serve as a useful reference.

@HumairAK
Copy link
Contributor Author

Related: #8104

@gregsheremeta
Copy link
Contributor

gregsheremeta commented Jul 3, 2024

I will begin working on this

edit: scratch that, I'm not going to work on (all) of this quite yet

@HumairAK
Copy link
Contributor Author

HumairAK commented Jul 3, 2024

/assign gregsheremeta

@gregsheremeta
Copy link
Contributor

partial duplicate of #6578

@gregsheremeta
Copy link
Contributor

/unassign @gregsheremeta

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

No branches or pull requests

2 participants