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): Use google.protobuf.Value in v2 for passing parameters. #6804

Merged
merged 26 commits into from
Oct 28, 2021

Conversation

neuromage
Copy link
Contributor

@neuromage neuromage commented Oct 26, 2021

This PR introduce support for passing parameters using google.protobuf.Value in v2. Previously, parameters were passed using a custom Value proto in the IR which supported int, double and string. Switching to protobuf.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 around None values, but I haven't thought this through just yet.

  • Fix tests
  • Remove print/debug lines

@google-cla google-cla bot added the cla: yes label Oct 26, 2021
@neuromage neuromage changed the title feat(sdk): Use google.protobuf.Value in v2 for passing parameters. [WIP] feat(sdk): Use google.protobuf.Value in v2 for passing parameters. Oct 26, 2021
# 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
Copy link
Member

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 :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@neuromage neuromage changed the title [WIP] feat(sdk): Use google.protobuf.Value in v2 for passing parameters. feat(sdk): Use google.protobuf.Value in v2 for passing parameters. Oct 27, 2021
Copy link
Member

@chensun chensun left a 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__)
Copy link
Member

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:

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:

# `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?

Copy link
Contributor Author

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.

@chensun
Copy link
Member

chensun commented Oct 27, 2021

@Bobgy , the samples-v2 test has been quite flaky for a while, do you have some bandwidth to look into it?
Also, can you please help take a look to see if the v2-go test failure is something we need to address in this PR?
Thanks!

@Bobgy
Copy link
Contributor

Bobgy commented Oct 27, 2021

The go v2 test fails with

go modules are not tidy, run 'go mod tidy'.

Note, you may need to run the command in the v2 folder.

EDIT: I pushed a commit to fix this.

@Bobgy
Copy link
Contributor

Bobgy commented Oct 27, 2021

@Bobgy , the samples-v2 test has been quite flaky for a while, do you have some bandwidth to look into it?

I will work with @capri-xiyue on this.

Copy link
Contributor

@Bobgy Bobgy left a 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;
Copy link
Contributor

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

Copy link
Contributor Author

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
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch, fixed.

@google-oss-robot
Copy link

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

@chensun
Copy link
Member

chensun commented Oct 27, 2021

/lgtm

Thanks!

@Bobgy
Copy link
Contributor

Bobgy commented Oct 27, 2021

There are still some failures with v2 compatible / v2 samples that we need to fix.
I think it's also worth discussing -- how do we develop v2 going forward?
The current pain point seems to be that, when a pipeline spec change is introduced, the SDK and backend have to be changed at the same time, so this one single PR will be huge (and requires someone who knows both SDK and backend to implement).

  1. Will it work out better if the SDK changes can be merged first gated by a temporary hidden flag? If the flag is enabled, all parameters are changed to protobuf.Value.
  2. Then people working on the backend can try to write their PRs separately with the hidden flag turned on in their PR.
  3. When the backend PR is merged, we clean up the hidden flag and legacy code.

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?

@Bobgy
Copy link
Contributor

Bobgy commented Oct 28, 2021

@Bobgy
Copy link
Contributor

Bobgy commented Oct 28, 2021

@Bobgy
Copy link
Contributor

Bobgy commented Oct 28, 2021

@chensun
Copy link
Member

chensun commented Oct 28, 2021

/lgtm

/test kubeflow-pipelines-samples-v2

@chensun
Copy link
Member

chensun commented Oct 28, 2021

/test kubeflow-pipelines-samples-v2

@chensun
Copy link
Member

chensun commented Oct 28, 2021

/lgtm

Thank you, @neuromage and @Bobgy

@google-oss-robot google-oss-robot merged commit 0be57c3 into kubeflow:master Oct 28, 2021
abaland pushed a commit to abaland/pipelines that referenced this pull request May 29, 2022
…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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants