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

[SDK] KFP SDK V2 Namespace Plan #7238

Closed
ji-yaqi opened this issue Feb 1, 2022 · 1 comment
Closed

[SDK] KFP SDK V2 Namespace Plan #7238

ji-yaqi opened this issue Feb 1, 2022 · 1 comment

Comments

@ji-yaqi
Copy link
Contributor

ji-yaqi commented Feb 1, 2022

Background

Previously on KFP SDK v1.x, we had two modes of import, signaling two different compilers with different compilation results.

  • import kfp imports KFP v1 and v2-compatible mode compiler
  • import kfp.v2 imports KFP v2 mode compiler

Two modes of import are confusing to the users. Although users are in SDK v1.x, they have kfp and kfp.v2 to choose from, where normally the package name (kfp) indicates the default versioning.

As KFP SDK evolves to v2.0 version, we want to set a standard way of importing KFP namespace, for easier usage and also cleaner code for maintenance.

Proposed Namespace for KFP SDK v2

Since the package name indicates the default versioning, we propose in KFP v2 and possible future iterations, we will always use kfp as the official namespace.

  • import kfp imports KFP v2 mode compiler

For v1-related features, users need to go back to SDK v1.x and use import kfp.

In this way, users don't need to change imports when they are experiencing major version updates.

For existing GA customers, we will provide an alias of kfp.v2 to kfp, and throw a warning if user uses kfp.v2. Full set of warnings will be documented in the migration guide.

Note:

  1. v2-compatible mode was launched as an experimental feature, so it won't appear in v2 SDK and follows cloud deprecation policy.

  2. For KFP SDK v1.x features, we will maintain it for 1 year after GA of SDK v2.0. After that, we will be providing security patches and major bug fixes for any bug that results in user code breaking until usage on GCP (Vertex and KFP) is 0.

User Impact on Namespace

  1. KFP V1 users migration (NO changes)
Current
from kfp import dsl
from kfp import compiler

@dsl.pipeline(name='my-pipeline')
def pipeline():
   ...

compiler.Compiler().compile(pipeline, 
'path')

  1. Vertex Pipeline users (primarily removing v2 from the imports).

Note: there are other changes suggested for Vertex Pipeline users which will be documented in the migration doc.

Current Anticipated change
from kfp.v2 import dsl
from kfp.v2 import compiler

@dsl.pipeline(name='my-pipeline')
def pipeline():
   ...

compiler.Compiler().compile(pipeline, 
'path')
from kfp import dsl
from kfp import compiler

@dsl.pipeline(name='my-pipeline')
def pipeline():
   ...

compiler.Compiler().compile(pipeline, 
'path')
  1. Component authors: libraries with dependencies on KFP (e.g. GCPC)
Current Anticipated change
from kfp.v2 import dsl

@dsl.component(
   packages_to_install=[
       'google-cloud-aiplatform', 
       'google-cloud-pipeline-components',
       'protobuf'
   ],
   base_image='python:3.7')

def GetTrialsOp(gcp_resources: str) -> list:
  …
from kfp import dsl

@dsl.component(
   packages_to_install=[
       'google-cloud-aiplatform', 
       'google-cloud-pipeline-components',
       'protobuf'
   ],
   base_image='python:3.7')

def GetTrialsOp(gcp_resources: str) -> list:
  …
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

1 participant