-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
fix(backend): Update backend common code and integration tests with updated API Service Params #10640
Conversation
… Params Signed-off-by: Giulio Frasca <gfrasca@redhat.com>
Signed-off-by: Giulio Frasca <gfrasca@redhat.com>
Hi @gmfrasca. Thanks for your PR. I'm waiting for a kubeflow 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. |
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.
/ok-to-test
Thanks @gmfrasca, seems like the integration test is passed but the upgrade test is failing. Feel free to let us know if you are blocked by anything in the ci/cd. |
/cc @chensun |
Update: So both tests are failing due to an issue with unexpected responses (see example error printout[1]). I tried tracing the error flow and while doing so noticed that the available schemes were reduced from http AND https to simply http (see example change in DefaultSchemes for various [1] errortext:
|
- **NOTE**: this was manually updated, tested, and verified locally uploading for CI check - It appears when regenerating the backend API, something in the generation libraries changed and now default the scheme to just http, not http+https, which appears to break tests. - Need to figure out what options to provide api generators to revert DefaultScheme to include https again automatically Signed-off-by: Giulio Frasca <gfrasca@redhat.com>
/hold Tested manually updating the DefaultScheme and Scheme values as I suspected in previous message. Local testing is promising, so pushing a WIP commit to see how CI fares. If it passes we need to figure out how to make sure API Generation includes the option |
Signed-off-by: Giulio Frasca <gfrasca@redhat.com>
alright, looks like all CI is passing as hoped, with just a very minor expected syntax update made. :) Given that, I did some more digging and found a change in grpc-gateway[1] that makes the schemes spec default to emptyset ( The following commit will have these changes made, but my testing infra has hibernated for the night so this is a shot in the dark that CI remains passing. Assuming it does, I believe this PR is ready for final review and can be unblocked. |
Signed-off-by: Giulio Frasca <gfrasca@redhat.com>
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
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
/approve
Thank you, @gmfrasca!
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: chensun 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 |
/unhold |
Description of your changes:
Fixes #10629 , Supercedes #10631
The 2.1.0 release updated the API Generator, which in turn updated the signature/names of most of the *Params APIs. This PR refactors all instances to use the newly generated naming schema
Checklist: