-
Notifications
You must be signed in to change notification settings - Fork 66
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 Nexus OutgoingService CRUD #370
Conversation
api-linter.yaml
Outdated
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.
Wasn't some of this in the other PR?
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.
Yes, this is meant to be a stacked PR. Should've put that in the description.
// Create a Nexus service. This will fail if a service with the same name already exists in the namespace with a | ||
// status of ALREADY_EXISTS. | ||
// Returns the updated service with its initial version. You may use this version for subsequent updates. You don't | ||
// need to increment the version yourself. The server will increment the version for you after each update. | ||
rpc CreateNexusOutgoingService(CreateNexusOutgoingServiceRequest) returns (CreateNexusOutgoingServiceResponse) { | ||
} | ||
|
||
// Update an outgoing Nexus service by namespace and service name. The version in the request should match the | ||
// current version of the service. This will fail with a status of FAILED_PRECONDITION if the version does not match. | ||
// Returns the updated service with the updated version, which can be used for subsequent updates. You don't need | ||
// to increment the version yourself. The server will increment the version for you. | ||
rpc UpdateNexusOutgoingService(UpdateNexusOutgoingServiceRequest) returns (UpdateNexusOutgoingServiceResponse) { | ||
} |
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.
Is it intentional to have separate create/update calls for outgoing but one create-or-update for incoming?
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'll also separate these for incoming in a followup PR.
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.
If we know we're going to do it, might as well do it in a common PR IMO. But if coming soon after, ok, though it's a bit hard to approve this PR not knowing what that will look like.
The separate PRs makes it hard to review as a whole. I was lucky enough have looked at the other Nexus APIs from other past PRs for consistency or I would have missed this inconsistency entirely (even though I'm sure y'all knew about it, it was unclear to me).
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'll submit a PR to follow this one once it's merged.
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.
The protos LGTM, please separate the linter change into a different PR.
568d21f
to
51307c6
Compare
Rebased with those on master now. |
What changed?
Add OperatorService APIs for managing Nexus services to which we will send traffic.
Why?
Breaking changes