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

copy matcher proto and dependencies from Envoy #8

Merged
merged 7 commits into from
Jul 21, 2021
Merged

Conversation

snowp
Copy link
Contributor

@snowp snowp commented Jul 9, 2021

Moves the Matcher proto into the udpa repo along with a few dependencies: TypedExtensionConfig, StringMatcher and RegexMatcher.

Signed-off-by: Snow Pettersen <[email protected]>
@snowp
Copy link
Contributor Author

snowp commented Jul 9, 2021

@htuch @markdroth

Signed-off-by: Snow Pettersen <[email protected]>
Copy link
Contributor

@markdroth markdroth 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 doing this!

These files should all be in the xds tree, not the udpa tree. We're moving away from udpa.

@@ -0,0 +1,24 @@
syntax = "proto3";

package udpa.extension.v1;
Copy link
Contributor

Choose a reason for hiding this comment

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

Should TypedExtensionConfig be in the xds.extension tree? Or should it be in xds.core? This isn't itself an extension; it's really a type used to point at an extension, which is a capability that is basically built into core.

@htuch
Copy link
Contributor

htuch commented Jul 12, 2021

Nice, thanks! Yep, agree that this should be in the xds/ tree and TypedExtensionConfig should be core.

Signed-off-by: Snow Pettersen <[email protected]>
Signed-off-by: Snow Pettersen <[email protected]>
Signed-off-by: Snow Pettersen <[email protected]>
@snowp
Copy link
Contributor Author

snowp commented Jul 14, 2021

@htuch @markdroth ptal, i made the moves

Also FYI I dropped reserved fields, deprecated fields, udpa annotations, etc. when copying these over

htuch
htuch previously approved these changes Jul 15, 2021
Copy link
Contributor

@htuch htuch left a comment

Choose a reason for hiding this comment

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

LGTM, will defer to Mark before merge. I think we need to port protoformat over to this repo at some point @phlax.

Copy link
Contributor

@markdroth markdroth left a comment

Choose a reason for hiding this comment

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

Just one potential issue about the java package names.

string name = 1 [(validate.rules).string = {min_len: 1}];

// The typed config for the extension. The type URL will be used to identify
// the extension. In the case that the type URL is *udpa.type.v1.TypedStruct*,
Copy link
Contributor

Choose a reason for hiding this comment

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

@htuch We'll need to remember to update this comment to use xds.type.v1.TypedStruct when we copy files as part of addressing #2.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ack


option java_outer_classname = "ExtensionProto";
option java_multiple_files = true;
option java_package = "com.github.udpa.xds.core.v1";
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, why is "udpa" part of this string? Looks like that's the case for the existing protos too. @htuch, is this something we can fix without breaking the API? We should probably try to take care of this as part of #2.

Also, this string should say "v3" instead of "v1".

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It would break the generated Java code, so we're extending API compatibility to generated code I don't think we can change it?

Fixed the version string

Copy link
Contributor

@htuch htuch Jul 19, 2021

Choose a reason for hiding this comment

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

But this is lift-and-shift across repos, so we don't have strict compatibility requirements, for API or code?

I think for existing protos we can take this on a case-by-case basis. gRPC folks are probably best positioned to know the Java implications for the various protos (ORCA, TypedStruct); the validation proto cases are not an issue IMHO.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure we could change the package of this new file to be com.github.xds.core.v1, but won't that make this inconsistent with the other packages in here? I was thinking about the idea of changing the java_package of all the protos in xds/ to not include udpa, which affects more than just this file

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 we should do the following:

  1. Decide what we want the java package path to be for all of the xds protos.
  2. Use the new path for these new files.
  3. Decide on a plan to fix the existing files. If we can just change them without breaking anything, we should do that; otherwise, we need to come up with an alternative deprecate-and-migrate plan.

@ejona86 may have some thoughts on how this affects things for Java.

Copy link

Choose a reason for hiding this comment

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

What is the migration process expected for this proto? It has a different package name and file path, so it seems like a brand new proto from protobuf's perspective. In that case, it is a new proto with no prior usages and the Java path can be anything but io.envoyproxy.envoy.config.core.v3 (to avoid colliding with the other copy).

Copy link

Choose a reason for hiding this comment

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

Mark spoke to me and made clear the issue is the existing files.

The existing files are already included in grpc-java, however, there aren't any references to the messages outside of generated code. That means that as long as the consuming protos are generated in the same build process as these protos we'd be fine. That is true for Google-internal and, since grpc-java is not using packages from maven-central but instead building and shading the generated code in grpc-xds. it would be true for the github builds of grpc-java as well.

So it seems fine to change these package names from grpc-java's perspective.

Copy link
Contributor

Choose a reason for hiding this comment

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

Okay, super, I'll send a separate PR to update the existing files.

Should we use com.github.cncf.xds instead of just com.github.xds, to avoid potential conflicts with some other github <something>/xds repo?

Copy link
Contributor

Choose a reason for hiding this comment

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

Actually, nevermind that last question -- we're already using xds as the top-level proto package, so com.github.xds is probably fine.

Copy link
Contributor

Choose a reason for hiding this comment

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

Sent #9 with the changes to the existing files.

Signed-off-by: Snow Pettersen <[email protected]>
Signed-off-by: Snow Pettersen <[email protected]>
@snowp
Copy link
Contributor Author

snowp commented Jul 19, 2021

Sorry about all the force pushes, I need to get my aliases right so I sign commits in repos without the pre-commit hooks :)

Copy link
Contributor

@htuch htuch left a comment

Choose a reason for hiding this comment

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

LGTM, thanks, will defer to Mark for final approval.

Copy link
Contributor

@markdroth markdroth left a comment

Choose a reason for hiding this comment

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

Looks great! We can follow up on fixing the java package path on the existing files separately.

@markdroth
Copy link
Contributor

Harvey, I don't have merge access on this repo, so you'll need to do that.

@htuch htuch merged commit a8536b9 into cncf:main Jul 21, 2021
@htuch
Copy link
Contributor

htuch commented Jul 21, 2021

@markdroth done, I've fixed it so you should be able to merge in the future.

htuch pushed a commit that referenced this pull request Jul 22, 2021
As discussed in #8.

Signed-off-by: Mark D. Roth <[email protected]>
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.

4 participants