-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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): Use google.protobuf.Value in v2 for passing parameters. #6804
Conversation
# Two different types being compared. The only possible types are | ||
# String, Boolean, Double and Integer. We'll promote the other type | ||
# using the following precedence: | ||
# String > Boolean > Double > Integer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't aware that CEL can work this way.
The rest of the change to support Protobuf.Value in condition operand is also very nice. I'm going to steal your code in my experimental fork :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Go for it :-) I used this as my reference btw: https://github.com/google/cel-spec/blob/master/doc/langdef.md#list-of-standard-definitions
Update goldens, cleanup, all that stuff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
Thanks!
@@ -11,3 +11,5 @@ | |||
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | |||
# See the License for the specific language governing permissions and | |||
# limitations under the License. | |||
|
|||
__path__ = __import__("pkgutil").extend_path(__path__, __name__) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is probably unnecessary because kfp-pipeline-spec
is a native namespace package when we set it up:
pipelines/api/v2alpha1/python/setup.py
Line 87 in 4360652
packages=setuptools.find_namespace_packages(include=['kfp.*']), |
ref: https://packaging.python.org/guides/packaging-namespace-packages/#native-namespace-packages
In comparison, to make the existing kfp
package a namespace package, we do have to include this in its init file:
pipelines/sdk/python/kfp/__init__.py
Lines 15 to 17 in 4360652
# `kfp` is a namespace package. | |
# https://packaging.python.org/guides/packaging-namespace-packages/#pkgutil-style-namespace-packages | |
__path__ = __import__("pkgutil").extend_path(__path__, __name__) |
Also this change is not released, so it can't be needed for this PR, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, left over while trying to get both namespace packages to work nicely while locally installed. Removed.
@Bobgy , the samples-v2 test has been quite flaky for a while, do you have some bandwidth to look into it? |
The go v2 test fails with
Note, you may need to run the command in the v2 folder. EDIT: I pushed a commit to fix this. |
I will work with @capri-xiyue on this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for taking this complex refactoring!
Some nit pickings first.
It's very difficult to review, so I prefer we put getting all tests passing as the only criteria to merge. I will start investigating test failures tomorrow and send PRs to the branch directly.
@@ -26,6 +27,7 @@ message CacheKey { | |||
map<string, RuntimeArtifact> outputArtifactsSpec = 3; | |||
map<string, string> outputParametersSpec=4; | |||
ContainerSpec containerSpec=5; | |||
map<string, google.protobuf.Value> input_parameter_values = 6; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: the other fields use camel case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, but proto style guide is explicitly underscore_separated_names for fields. This is what's used everywhere else as well:
https://developers.google.com/protocol-buffers/docs/style#message_and_field_names
My suggestion is to adopt the right style here for long term health, and consider replacing the camel case ones in a future PR.
@@ -27,6 +27,8 @@ def args_generator_op() -> List[str]: | |||
def print_op(msg: str): | |||
print(msg) | |||
|
|||
dsl.ParallelFor |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: is this a typo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, fixed.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: chensun 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 |
/lgtm Thanks! |
There are still some failures with v2 compatible / v2 samples that we need to fix.
Another option I can think of is what we are doing now: let people from SDK/backend work together on a single PR. We can let the PR author give PR branch push permission to other collaborators, so they work together on the PR focusing on SDK/backend. What do you think? |
I'm examining failure of a v2 engine hello world sample: https://4e18c21c9d33d20f-dot-datalab-vm-staging.googleusercontent.com/#/runs/details/9aafca2c-a958-4e23-85e9-e3c517ead3fb. |
Last failure fixed, new failure: https://4e18c21c9d33d20f-dot-datalab-vm-staging.googleusercontent.com/#/runs/details/c3721d7a-83b5-4742-9efe-c171205bd366 |
v2 hello world is passing: https://4e18c21c9d33d20f-dot-datalab-vm-staging.googleusercontent.com/#/runs/details/85863efb-ff41-43a3-b506-b7aac70982c7 |
/lgtm /test kubeflow-pipelines-samples-v2 |
/test kubeflow-pipelines-samples-v2 |
/lgtm Thank you, @neuromage and @Bobgy |
…ubeflow#6804) * Use google.protobuf.Value in v2 for passing parameters. * retest samples. * Fix tests. * Update release, more cleanup. * Use github.com/kubeflow/pipelines/api from same repo. * Run go mod tidy * chore: go mod tidy * fix v2 compile error and clean up unused code * pr comments. * update goldens * Fix metadata recording. * Update kfp mlmd client. * fix test again * another try. * chore: migrate v2 DAG driver input parameters to protobuf.Value + small refactorings * fix v2 launcher + clean up * fix a compile error * fix a few more tests * fix number parsing * clean up * disable cache_v2 test. Co-authored-by: Yuan Gong <[email protected]>
This PR introduce support for passing parameters using
google.protobuf.Value
in v2. Previously, parameters were passed using a customValue
proto in the IR which supportedint
,double
andstring
. Switching toprotobuf.google.Value
allows us to pass JSON-able Python objects such as lists and dicts, and booleans in addition to scalar string and number values.We should also look into using
null
to pass aroundNone
values, but I haven't thought this through just yet.