-
Notifications
You must be signed in to change notification settings - Fork 503
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
Implement GRPCRoute (GEP 1016) #1115
Implement GRPCRoute (GEP 1016) #1115
Conversation
Hi @gnossen. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/ok-to-test |
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.
One other comment - it would be good to squash the commits (it's all one logical change, unless you wanted to have the autogen stuff in a separate commit) and at least add to the commit message the GEP number you're implementing
Just trying to smooth the way to merging. HTH
Service *string `json:"service,omitempty"` | ||
|
||
// Value of the method to match against. If left empty or omitted, will | ||
// match all services. |
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 empty/omitted match all only if Type=Exact?
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.
No. The behavior of our prototype implementation will match all regardless of the value of type.
However, I don't feel strongly about this, if you have a compelling reason to match all only when Type=Exact
.
// implementation must raise an 'Accepted' condition with a status of | ||
// 'False' in the corresponding RouteParentStatus. | ||
// | ||
// Support: Core |
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 thinking about what it means for GRPC specific stuff to be marked as Core if GRPCRoute itself is Extended
Referring to: https://gateway-api.sigs.k8s.io/concepts/guidelines/#overlapping-support-levels
Since these fields are never embedded in a struct with Core support level, then these fields can never be Core?
So ... it's just a nod to "when GRPCRoute becomes Core, some fields will be Core and some will be Extended" ?
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.
No, the idea here is that this feature is Core to the GRPCRoute
feature. Independent of that, GRPCRoute
is extended relative to the Gateway API. There was previously a discussion on that topic here.
@markmc Thanks for the review. Sorry for the turnaround time on the response. As for squashing, that's going to be a little more difficult now that I've merged master in. Is it not possible to enable auto-squashing on the repo if that is the preferred commit history style? |
d4f4100
to
73158df
Compare
73158df
to
2860f03
Compare
63f956f
to
bf3d3e0
Compare
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.
Mostly looks LGTM, but I think we need to backport some of the changes we made to HTTPRoute for v0.5.0 about BackendRefs. I'm not one hundred percent sure the semantics are the same for GRPCRoute, but we need to review at least.
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 @gnossen! This mostly LGTM.
bf3d3e0
to
eb297cf
Compare
@hbagdi I'm not sure why I'm not able to respond to this comment directly, so I'm responding here. I'm thinking this must be a typo? The spec requires that implementations supporting GRPCRoute with the I'm guessing you meant
If so, the answer is "not really." AFAIK, this would not be useful to any of the existing gRPC clients and servers in the wild. It would more or less be a broken implementation. |
bf23c5d
to
c88e329
Compare
c88e329
to
1eba178
Compare
1eba178
to
493e897
Compare
Thanks for all the work on this @gnossen! Discussed at community meeting today and there were no concerns about merging this in. Will plan to merge this at some point tomorrow unless else someone LGTMs before then (that's also welcome). /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gnossen, robscott 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 |
What type of PR is this?
/kind feature
/kind api-change
What this PR does / why we need it:
Fixes #1016
Does this PR introduce a user-facing change?: