-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
deps: upgrade grpc-ecosystem/go-grpc-middleware to v2 #17892
Conversation
Hi @marefr. Thanks for your PR. I'm waiting for a etcd-io 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 |
upgrades grpc-ecosystem/go-grpc-middleware to v2 Signed-off-by: Marcus Efraimsson <marcus.efraimsson@gmail.com>
Co-authored-by: Benjamin Wang <benjamin.wang@broadcom.com> Signed-off-by: Marcus Efraimsson <marcus.efraimsson@gmail.com>
131abc4
to
613ea90
Compare
It seems that the grpc-proxy changes the behaviour. The existing main branch could print the payload, but this PR doesn't print the payload anymore. Main branch
This PR
|
Refer to #14266 (comment) |
) | ||
|
||
// settableLoggerV2 is thread-safe. | ||
// Copied from https://github.com/grpc-ecosystem/go-grpc-middleware/tree/v1.4.0/logging/settable. |
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.
We have already upgraded to grpc-ecosystem/go-grpc-middleware/v2
in this PR, I am a little concerned why we still need to copy code from grpc-ecosystem/go-grpc-middleware v1
? Is it possible to do it in consistent & v2 style?
Also link to the original PR which introduced the var grpc_logger grpc_logsettable.SettableLoggerV2
in integration test. #12781
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.
logsettable package was removed in v2 so I opted to copy from v1 in lack of alternative.
cc @stefanmonkey who is the author of the PR #14266 |
Signed-off-by: Marcus Efraimsson <marcus.efraimsson@gmail.com>
Thanks for spotting this. Changed to use the payload received/sent events instead of start/finish call events for the logger interceptor. However, it doesn't look promising 😢
The error
Thoughts? |
/retest |
Thanks for your effort so far.
Yes, it's true and the option 1 is definitely my preference. It's one of the tech debts which etcd has. There is an issue #14533 to track the effort. But unfortunately, I do not get time to work on it. No people work on it either. It would be great If you are interested and have bandwidth to work on it, and I am happy to provide whatever help.
Please feel free to raise a separate PR to resolve it. I think it can be approved & merged soon. |
FYI. We faced similar issue previously when we upgraded grpc-gateway from v1 to v2 |
Understood and thanks for the pointer. Not sure I have the etcd knowledge needed nor bandwidth I'm afraid. Quite hard to see how much changes and possibly breaking changes this might require. I do have quite good understanding of protobuf so if I get time I might try and upgrade and see what changes/breaks and report back in the issue. Might help to break up the work needed? Or have anyone already tried this already perhaps? It didn't seem like it in the issue.
|
Follow up from #17884. Upgrades github.com/grpc-ecosystem/go-grpc-middleware to v2.
Ref #17883
From #17884 (review):
New
GrpcLoggerInterceptor
function (copied from here) added to existing client/pkg/logutil package. Suggest moving to pkg/logutil in a separate PR. Let me know what you think.Regarding
tests/framework/integration/settable_logger.go
I copied that from here. I did consider copying the tests as well, but wasn't sure it made sense to have unit tests in the framework/integration package. Then I thought, maybe an internal package would make sense, but wasn't sure that would fit in the framework/integration package either. I left it in the integration package for now, but did change to make it non-exportable. Let me know if you have a better idea here.