-
Notifications
You must be signed in to change notification settings - Fork 72
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
Conversation
Signed-off-by: Snow Pettersen <[email protected]>
Signed-off-by: Snow Pettersen <[email protected]>
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 for doing this!
These files should all be in the xds tree, not the udpa tree. We're moving away from udpa.
udpa/extension/v1/extension.proto
Outdated
@@ -0,0 +1,24 @@ | |||
syntax = "proto3"; | |||
|
|||
package udpa.extension.v1; |
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.
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.
Nice, thanks! Yep, agree that this should be in the |
Signed-off-by: Snow Pettersen <[email protected]>
Signed-off-by: Snow Pettersen <[email protected]>
Signed-off-by: Snow Pettersen <[email protected]>
@htuch @markdroth ptal, i made the moves Also FYI I dropped reserved fields, deprecated fields, udpa annotations, etc. when copying these over |
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, will defer to Mark before merge. I think we need to port protoformat
over to this repo at some point @phlax.
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.
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*, |
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.
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.
Ack
xds/core/v3/extension.proto
Outdated
|
||
option java_outer_classname = "ExtensionProto"; | ||
option java_multiple_files = true; | ||
option java_package = "com.github.udpa.xds.core.v1"; |
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.
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.
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
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.
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.
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.
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
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 we should do the following:
- Decide what we want the java package path to be for all of the xds protos.
- Use the new path for these new files.
- 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.
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.
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).
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.
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.
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.
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?
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.
Actually, nevermind that last question -- we're already using xds
as the top-level proto package, so com.github.xds
is probably fine.
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.
Sent #9 with the changes to the existing files.
Signed-off-by: Snow Pettersen <[email protected]>
Signed-off-by: Snow Pettersen <[email protected]>
Sorry about all the force pushes, I need to get my aliases right so I sign commits in repos without the pre-commit hooks :) |
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, thanks, will defer to Mark for final approval.
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.
Looks great! We can follow up on fixing the java package path on the existing files separately.
Harvey, I don't have merge access on this repo, so you'll need to do that. |
@markdroth done, I've fixed it so you should be able to merge in the future. |
As discussed in #8. Signed-off-by: Mark D. Roth <[email protected]>
Moves the Matcher proto into the udpa repo along with a few dependencies: TypedExtensionConfig, StringMatcher and RegexMatcher.