-
Notifications
You must be signed in to change notification settings - Fork 256
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
Add support for NetworkConfigProxy v0 and v1 api #1797
Add support for NetworkConfigProxy v0 and v1 api #1797
Conversation
proto is failing cause of formatting in the generated you could manually change the files, or use go 1.19 locally, or upgrade the pipeline to 1.20 |
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.
Isn't this a pretty major breaking change, since anyone currently using the v1 API will have their code break suddenly?
Can we keep the original v1
name, but instead call the old package v1legacy
or something like that?
1a567c5
to
2d3af1d
Compare
Yes, this is a breaking change, however, afaik, no one is using the |
I'd suggest we keep the latest proto file unchanged, and just add the old one in a package dir named something like v0/legacy/beta/etc. That way it's not a breaking change to anyone. |
2d3af1d
to
f6ac0be
Compare
I think PR title/description need to be updated. |
f6ac0be
to
5b24159
Compare
I'm confused by this comment. Isn't running v0 and v1 at the same time precisely what this PR is doing? |
@kevpar This PR adds the ability to use v0 or v1 within the same executable for ncproxy. This was more of an implementation decision that I made. Since the code works by converting the v0 api to the v1 api and back for the response, if both apis are being used simultaneously, it's possible there are "ncproxy networks" or "ncproxy endpoints" that were created from a call to the v1 apis. In that scenario, a v0 agent making a call to something like "GetNetworks" would get an error since there are "ncproxy networks" that ncproxy is tracking which cannot be encoded in the response to the v0 "GetNetworks" api. We could instead just ignore "ncproxy networks" or "ncproxy endpoints" and add a log on our side, but I was concerned about doing that since we wouldn't be giving the node network agent the true picture of what networks or endpoints have been created through calls to ncproxy. So basically the expectation is that if node network agent wants to use the v1 api, it must fully move all calls to ncproxy over to the v1 api, not just a subset. This will hopefully additionally prevent some bugs that could show up if they only move a subset of the calls to the newer api. |
Okay, it's just that callers can't use both the v0 and v1 API at the same time with a single ncproxy instance? The phrasing made it sound like we can't host both APIs at the same time. Edit: I think it would probably be better if we can just show a limited view in the v0 API, rather than returning an error. For instance, just filter out the "ncproxy networks" in v0 |
@kevpar Sure, if that's what's preferred, I'll make those changes now. |
5b24159
to
6aa6628
Compare
@kevpar code now allows for running both v0 and v1 api simultaneously. IOW, no erroring if "ncproxy networks" or "ncproxy endpoints" are present. |
6aa6628
to
32cb20f
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.
LGTM
32cb20f
to
4a105f7
Compare
Fixed a linter error in the naming of the new error variables I made. |
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 was the decision on log warnings in all the v0 calls that the API is marked for deprecation and users should transition to v1?
* Add tests for NetworkConfigProxy v0 support Signed-off-by: Kathryn Baldauf <kabaldau@microsoft.com>
4a105f7
to
cbb43e5
Compare
I added a warning log in the server setup to indicate that the v0 api is deprecated. Unfortunately, as far as I could find, there isn't a nice way to indicate that a field or api call is deprecated without adding deprecated tags to the proto files and having the node network agent take that updated proto file for v0 api. We could add a log statement to all the functions for v0, but that wouldn't communicate to the node network agent that the field is deprecated, that would just add a log in our own ncproxy logs, which I'm not sure would be useful. |
Signed-off-by: Kathryn Baldauf <kabaldau@microsoft.com>
@helsaawy and @kevpar I added an additional option in the v0 protobuf file to indicate that it's deprecated. Based on the language spec https://protobuf.dev/programming-guides/proto3/, this typically just produces a warning when the file is compiled, so should be fine to add. |
The protobuf docs seem to indicate that this option is only valid at field scope, rather than file. However, both protoc-gen-gogo and protoc-gen-go seem to generate a comment based on it being set at file-scope, so I guess it's fine? |
Yeah, I saw a reference to using the option at a file level here. I chose to do this to avoid needing to add the option to every type in the proto, but I'm fine adding that if that's the level of verbosity we'd prefer here. |
The current approach is fine with me. |
This PR adds support to ncproxy service for both the NetworkConfigProxy grpc v0 and v1 api. This is done by converting the v0 api to the v1 api before calling the underlying implementation of the various ncproxy calls and converting from the v1 responses to the v0 responses before returning the results. This PR additionally adds tests for the v0 api.
Currently with the NetworkConfigProxy v1 api, ncproxy supports two types of networking: hcn networking and ncproxy networking. NetworkConfigProxy grpc v0 api notably does not have support for the ncproxy networking types, dual stack, or the additional hcn policies that are present in the v1 api.
Note: v0 support is intended to be temporary, so this code will likely be removed in the near future.