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

feat(sdk): add PipelineConfig to DSL to re-implement pipeline-level config #11112

Merged

Conversation

gregsheremeta
Copy link
Contributor

@gregsheremeta gregsheremeta commented Aug 17, 2024

Description of your changes:

KFP v1 supported setting pipeline-level configuration via a PipelineConf class. This class was deprecated and no replacement was added to KFP v2.

Add new PipelineConfig class to support setting pipeline-level configuration in KFP v2.

Note: I discussed this approach with @chensun in the KFP Community meeting on August 14 (agenda, recording). He gave preliminary approval for this approach.

Here's an example of how it would be used.

Followup to #11333.

Checklist:

@DharmitD
Copy link
Contributor

/rerun-all

@gregsheremeta
Copy link
Contributor Author

@chensun bump to the top of your inbox :) thanks!

@gregsheremeta gregsheremeta force-pushed the kfp-dsl-pipeline-config branch from c7ba3f6 to 064c670 Compare August 29, 2024 17:53
@gregsheremeta
Copy link
Contributor Author

@chensun bump, looking for an ack on the approach and the proto fields :)

@gregsheremeta
Copy link
Contributor Author

@chensun bumping, can you take a look?

@gregsheremeta
Copy link
Contributor Author

gregsheremeta commented Sep 11, 2024

Sharing the document that @chensun provided in today's KFP Community meeting (agenda, recording) :

[External] Notes - Discuss PipelineConfig - Google Docs
https://docs.google.com/document/d/1Av9sWpluH9KhP2hAgpNRCJhqN_xI3Cb8bfaIeNf6ltk/edit#heading=h.lngiup14o4uj

@gregsheremeta
Copy link
Contributor Author

Thanks for discussing this internally. Here are my responses.

Actions items:
Ask community contributors to provide real world use cases and override designs for further evaluation.

Some examples:

Ask community contributors to evaluate PlatformSpec as an alternative place to add PipelineConf

I'm fine to put it wherever you all think is best. To clarify, is PlatformSpec the second document at the bottom?

root:
  dag:
    tasks:
      comp:
        cachingOptions:
          enableCache: true
        componentRef:
          name: comp-comp
        taskInfo:
          name: comp
schemaVersion: 2.1.0
sdkVersion: kfp-2.7.0
---
platforms:
  kubernetes:
    deploymentSpec:
      executors:
        exec-comp:
          emptyDirMounts:
          - medium: Memory
            mountPath: /mnt/my_vol_1
            sizeLimit: 1Gi
            volumeName: emptydir-vol-1

And if so, about where should pipeline-level stuff go? Should it be a sibling of kubernetes? Note that this was my approach in #10942 -- quoting from that

# PIPELINE DEFINITION
# Name: test-ttl-pipeline
components:
  comp-empty-component:
    executorLabel: exec-empty-component
deploymentSpec:
  completedPipelineTtl: 120
SNIP

but I (perhaps mistakenly) thought that that was rejected.

@gregsheremeta
Copy link
Contributor Author

@chensun bumping to the top of your inbox. Can you provide guidance on the spec questions in my previous comment?

@rimolive
Copy link
Member

@chensun As we discussed in the last Pipelines WG meeting, we need your inputs about Greg comments.

@chensun
Copy link
Member

chensun commented Oct 8, 2024

Apologize for the slow response.

I'm fine to put it wherever you all think is best. To clarify, is PlatformSpec the second document at the bottom?

Correct

And if so, about where should pipeline-level stuff go? Should it be a sibling of kubernetes? Note that this was my approach in #10942 -- quoting from that

kubernetes is meant for all features generic to kubernetes, the other platform exists today is google_cloud. So if we think a feature can be applied to all kubernetes-based platform (including Argo, Tekton), we can add the feature under it. Otherwise, if there's an Argo-specific feature that does not apply to KFP-Tekton, we may consider creating a sibling to kubernetes as argo. For TTL, I think it should be under kubernetes.

In terms of where specifically, pipeline level config doesn't exists yet. I think we may want to add it as a sibling to the deployment_config, which is the component-level:

PlatformDeploymentConfig deployment_spec = 1;

This would needs some proper design.

@HumairAK HumairAK added this to the KFP 2.4.0 milestone Oct 8, 2024
@gregsheremeta
Copy link
Contributor Author

@chensun confirming what we talked about on the call today. Hypothetically, say we're adding a feature to do both pipeline-level and pod-level TTL configs. We agreed those are not argo-specific or tekton-specific -- they belong in "kubernetes". So they would look like this:

<SNIP>
schemaVersion: 2.1.0
sdkVersion: kfp-2.8.0
---
platforms:
  kubernetes:
    pipelineConfig:
      pipelineTtl: "120"
    deploymentSpec:
      executors:
        exec-my-component:
          podTtl: "240"

Look right to you?

@chensun
Copy link
Member

chensun commented Oct 9, 2024

@chensun confirming what we talked about on the call today. Hypothetically, say we're adding a feature to do both pipeline-level and pod-level TTL configs. We agreed those are not argo-specific or tekton-specific -- they belong in "kubernetes". So they would look like this:

<SNIP>
schemaVersion: 2.1.0
sdkVersion: kfp-2.8.0
---
platforms:
  kubernetes:
    pipelineConfig:
      pipelineTtl: "120"
    deploymentSpec:
      executors:
        exec-my-component:
          podTtl: "240"

Look right to you?

Yes!

@HumairAK HumairAK modified the milestones: KFP 2.4.0, KFP SDK 2.11 Oct 10, 2024
@gregsheremeta gregsheremeta force-pushed the kfp-dsl-pipeline-config branch from 064c670 to 33b410a Compare October 24, 2024 18:40
@gregsheremeta gregsheremeta force-pushed the kfp-dsl-pipeline-config branch from 33b410a to 3e3972f Compare October 28, 2024 19:18
@gregsheremeta gregsheremeta force-pushed the kfp-dsl-pipeline-config branch 2 times, most recently from 9525a11 to 88887ba Compare October 28, 2024 23:16
@github-actions github-actions bot added the ci-passed All CI tests on a pull request have passed label Oct 28, 2024
KFP v1 supported setting pipeline-level configuration via a
`PipelineConf` class. This class was deprecated and no replacement
was added to KFP v2.

add new PipelineConfig class to support setting pipeline-level
configuration in KFP v2.

Co-authored-by: Ricardo M. Oliveira <rmartine@redhat.com>

Signed-off-by: Greg Sheremeta <gshereme@redhat.com>
@gregsheremeta gregsheremeta force-pushed the kfp-dsl-pipeline-config branch from 88887ba to 226902b Compare October 29, 2024 15:00
@google-oss-prow google-oss-prow bot added size/M and removed size/XXL labels Oct 29, 2024
@github-actions github-actions bot added ci-passed All CI tests on a pull request have passed and removed ci-passed All CI tests on a pull request have passed labels Oct 29, 2024
@rimolive
Copy link
Member

/lgtm

Copy link
Contributor

@DharmitD DharmitD left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested these changes locally and verified these work as expected.

/lgtm

@HumairAK
Copy link
Collaborator

Thanks folks.

/approve

Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: HumairAK

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@google-oss-prow google-oss-prow bot merged commit df4d787 into kubeflow:master Oct 29, 2024
26 checks passed
@HumairAK HumairAK modified the milestones: KFP SDK 2.11, KFP SDK 2.10 Oct 29, 2024
@sridhar1029
Copy link

@gregsheremeta I see that this change was merged but nothing was added to the Pipeline level config (sdk/python/kfp/dsl/pipeline_config.py)
Is there a plan to add config options in later versions? something like example you talked about (#11113)

@jgarciao
Copy link

@sridhar1029 I think the ttl configuration flag will be added in this follow-up task #10899

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved ci-passed All CI tests on a pull request have passed lgtm size/M
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants