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

cel: Add canonical CEL (dev.cel.expr) fields #89

Merged
merged 3 commits into from
Mar 29, 2024

Conversation

sergiitk
Copy link
Contributor

@sergiitk sergiitk commented Mar 19, 2024

This PR adds canonical CEL (https://github.com/google/cel-spec/tree/master/proto/cel/expr) fields to xds.type.v3.CelExpression. Canonical CEL cel.expr was created identical to the google.api.expr.v1alpha1, but may be extended in a backward-compatible way.

Nuances:

  1. The new fields cel_expr_parsed and cel_expr_checked are added outside of oneof expr_specifier per updated policy change: API: change style guide to discourage use of "oneof" envoyproxy/envoy#30851
  2. option (validate.required) = true is removed from the oneof expr_specifier, so the users may not presume one of the parsed_expr, checked_expr will be set.

Related:

  1. This replaces original PR cel: Add canonical CEL (dev.cel.expr) fields #75, which was rolled back to address the issue with go build Get cel.dev/expr error with go get #76. The orginal PR was approved by @markdroth.
  2. Go build CI verification added in Add go build CI job #78.
  3. cel.dev/expr domain is configured to redirect to google/cel-spec, which has go.mod and protobuf published in Add golang module for canonical protos. Move existing go module under tests google/cel-spec#342 / v1.15.0.
  4. Downstream envoy PR: deps: Bump com_github_cncf_xds to cncf/xds@0c46c01 envoyproxy/envoy#33160. cncf/xds version will be updated once this PR is merged.
    1. Envoy internal tracking: b/282949246.
  5. Closes spanner: cannot find module providing package cel.dev/expr googleapis/google-cloud-go#9031.
  6. Fixes Get cel.dev/expr error with go get #76.

sergiitk and others added 3 commits March 27, 2024 21:51
This PR adds canonical CEL
(https://github.com/google/cel-spec/tree/master/proto/cel/expr) fields
to `xds.type.v3.CelExpression`. Canonical CEL `cel.expr` was created
identical to the `google.api.expr.v1alpha1`, but may be extended in a
backward-compatible way.

Nuances: 1. The new fields `cel_expr_parsed` and `cel_expr_checked` are
added outside of `oneof expr_specifier` per updated policy change:
envoyproxy/envoy#30851 2. `option
(validate.required) = true` is removed from the `oneof expr_specifier`,
so the users may not presume one of the `parsed_expr`, `checked_expr`
will be set.

Signed-off-by: Sergii Tkachenko <sergiitk@google.com>
Signed-off-by: Sergii Tkachenko <sergiitk@google.com>
Signed-off-by: Sergii Tkachenko <sergiitk@google.com>
@sergiitk
Copy link
Contributor Author

For posterity, the fix for the go build (besides the domain setup) was implemented in google/cel-spec#342.

@sergiitk
Copy link
Contributor Author

@phlax please review. cc @tyxia.

@phlax
Copy link
Member

phlax commented Mar 28, 2024

@sergiitk im not a maintainer of this repo

cc @adisuissa

Copy link

@adisuissa adisuissa left a comment

Choose a reason for hiding this comment

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

Thanks for contributing!
I don't have a comment about the way you implemented this (LGTM), but left a general comment highlighting the issue that this brings into the eco-system.

@@ -29,10 +29,14 @@ EXTERNAL_PROTO_GO_BAZEL_DEP_MAP = {
# go_googleapis in https://github.com/bazelbuild/rules_go/blob/master/go/dependencies.rst#overriding-dependencies
"@com_google_googleapis//google/api/expr/v1alpha1:checked_proto": "@go_googleapis//google/api/expr/v1alpha1:expr_go_proto",
"@com_google_googleapis//google/api/expr/v1alpha1:syntax_proto": "@go_googleapis//google/api/expr/v1alpha1:expr_go_proto",
"@dev_cel//proto/cel/expr:checked_proto": "@dev_cel//proto/cel/expr:checked_go_proto",

Choose a reason for hiding this comment

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

IIUC these are introduced in addition to the com_googleapis variant to avoid introducing a breaking API change. However, as this is a superset of the com_googleapis project, then I think that conceptually it needs to replace it completely (to avoid violating ODR).
I'm a bit concerned what will happen if these two repos diverge. but as we don't have versioning in place, I don't think we can do much about it.
cc @htuch if there are other ways here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@adisuissa Canonical CEL (cel.dev) is meant to replace v1alpha1 CEL from google APIs package. Canonical CEL will always be extended in a backward-compatible way (as protos normally should be), so there isn't a divergence problem. I'm CCing CEL folks here for more context: @l46kok, @TristonianJones.
Also, @tyxia has more context from the Envoy side.

Copy link

@tyxia tyxia Mar 29, 2024

Choose a reason for hiding this comment

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

From Envoy perspective, cel.dev and v1alpha1 will co-exist. They are guaranteed to be in sync by CEL team.

New users in Envoy are recommended to use cel.dev while existing users can still use v1alpha1

Thus, v1alpha1 is deprecated but can not be removed.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think this makes sense. When the Envoy PR lands, which shoudl be adding implementation level support (not just API import), it might make sense to audit any remaining references to CEL that goes direct to google.api package namespace in the API protos in envoyproxy/envoy, e.g. RBAC.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Looks like nothing is blocking this PR from being merged, right?

@sergiitk sergiitk requested a review from adisuissa March 29, 2024 16:10
@adisuissa adisuissa merged commit 0c46c01 into cncf:main Mar 29, 2024
4 checks passed
@sergiitk sergiitk deleted the canonical-cel branch March 29, 2024 20:09
@mmorel-35
Copy link
Contributor

Hi @sergiitk ,
Just in case you are interested, I have pushed cel-spec 0.14.0 to BCR bazelbuild/bazel-central-registry#1641
It might integrate MODULE.bazel to it so it can then be published on BCR with the dédicated bot

@sergiitk
Copy link
Contributor Author

Thanks @mmorel-35. AFAIK this repo is not using bazel modules yet. Could you please let CEL folks know about it? They'll likely to be interested in including it into their docs.

@mmorel-35
Copy link
Contributor

Ok, I created an issue so they can have a look.

google/cel-spec#348

Copy link

@krzysztof293 krzysztof293 left a comment

Choose a reason for hiding this comment

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

Krzysztof293

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

Successfully merging this pull request may close these issues.

spanner: cannot find module providing package cel.dev/expr Get cel.dev/expr error with go get
7 participants