-
Notifications
You must be signed in to change notification settings - Fork 573
Service definition for OOP adapter that will be on session plan. #406
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
Conversation
import "google/protobuf/any.proto"; | ||
import "google/rpc/status.proto"; | ||
|
||
// `AdapterService` is implemented by backends that wants to provide telemetry and policy functionality to Mixer as an |
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.
Can we call this InfrastructureService instead?
These things are not adapters, they're just 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.
I agree they are not adapters. However, I feel Infrastructure is also not super helpful; But don't have any other suggestions. And I also think we can drop the suffix Service
.
How about few options that intent do imply Istio integration backends.
- InfrastructureIntegration ?
- InfrastructureIntegrationBackend ?
- IstioIntegration ?
- IstioIntegrationBackend ?
I like #1 because it is uses the terms we commonly use around Istio and is yet generic enough to make back-ends feel they are not completely locked into Istio.
@mandarjog @douglas-reid for their opinions
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 agree they are not adapters. However, I feel Infrastructure is also not super helpful; But don't have any other suggestions. And I also think we can drop the suffix Service
.
How about few options that intent do imply Istio integration backends.
- InfrastructureIntegration ?
- InfrastructureIntegrationBackend ?
- IstioIntegration ?
- IstioIntegrationBackend ?
I like #1 because it is uses the terms we commonly use around Istio and is yet generic enough to make back-ends feel they are not completely locked into Istio.
@mandarjog @douglas-reid for their opinions
Thoughts ?
// | ||
// For a given `AdapterService`, Mixer calls the `Validate` function, followed by `CreateSession`. The `session_id` | ||
// returned from `CreateSession` is used to make subsequent request-time Handle calls and the eventual `CloseSession` function. | ||
// Mixer assumes that, given the `session_id`, the backend can retrive the necessary context to serve the |
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.
retrieve
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.
D
// The `session_id` provides the Handle functions a way to retrive the necessary configuration associated with the session. | ||
// Upon Mixer configuration change, Mixer will re-invoke `CreateSession` for all handler configurations whose existing | ||
// sessions are invalidated or didn't existed. | ||
rpc CreateSession(CreateSessionRequest) returns (CreateSessionResponse); |
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 should mention that a backend is allowed to return the same session id if given the same config block. This would happen when multiple instances of Mixer in a deployment all create sessions with the same config.
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.
Note that given CloseSession, reusing session_id assumes the backend is doing refcounting.
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.
D
rpc CreateSession(CreateSessionRequest) returns (CreateSessionResponse); | ||
|
||
// Closes the session associated with the `session_id`. Mixer closes a session when its associated handler | ||
// configuration or the instance configuration changes. Backend is suppose to cleanup all the resources associated |
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.
supposed
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.
D
420b77a
to
27126f5
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.
Thanks @geeknoid for the review. PTAL at the changes. Also added some suggestions on the service name
// | ||
// For a given `AdapterService`, Mixer calls the `Validate` function, followed by `CreateSession`. The `session_id` | ||
// returned from `CreateSession` is used to make subsequent request-time Handle calls and the eventual `CloseSession` function. | ||
// Mixer assumes that, given the `session_id`, the backend can retrive the necessary context to serve the |
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.
D
// The `session_id` provides the Handle functions a way to retrive the necessary configuration associated with the session. | ||
// Upon Mixer configuration change, Mixer will re-invoke `CreateSession` for all handler configurations whose existing | ||
// sessions are invalidated or didn't existed. | ||
rpc CreateSession(CreateSessionRequest) returns (CreateSessionResponse); |
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.
D
rpc CreateSession(CreateSessionRequest) returns (CreateSessionResponse); | ||
|
||
// Closes the session associated with the `session_id`. Mixer closes a session when its associated handler | ||
// configuration or the instance configuration changes. Backend is suppose to cleanup all the resources associated |
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.
D
import "google/protobuf/any.proto"; | ||
import "google/rpc/status.proto"; | ||
|
||
// `AdapterService` is implemented by backends that wants to provide telemetry and policy functionality to Mixer as an |
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 agree they are not adapters. However, I feel Infrastructure is also not super helpful; But don't have any other suggestions. And I also think we can drop the suffix Service
.
How about few options that intent do imply Istio integration backends.
- InfrastructureIntegration ?
- InfrastructureIntegrationBackend ?
- IstioIntegration ?
- IstioIntegrationBackend ?
I like #1 because it is uses the terms we commonly use around Istio and is yet generic enough to make back-ends feel they are not completely locked into Istio.
@mandarjog @douglas-reid for their opinions
Thoughts ?
We've generally referred to these things as "infrastructure backends", so I think that would make a fine name. So I'll put my vote down for #5: InfrastructureBackend |
// | ||
// If the backend couldn't create a session for a specific handler configuration and | ||
// returns non S_OK status, Mixer will not make request-time Handle calls associated with that handler configuration. | ||
|
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.
Remove empty line.
@@ -0,0 +1,117 @@ | |||
// Copyright 2018 Istio Authors |
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.
Maybe rename the file?
@mandarjog over to you now for second lgtm. PTAL. |
@mandarjog I am getting this in, since it is needed by my next PRs. Feel free to leave comment and I can address them in a separate PR. Thanks. |
@douglas-reid I sneaked this in while you were out. Feel free to suggest improvements if you see anything that is not right. I can definitely use as many reviews as possible on this external API definition. @mandarjog you too :-). It is a lot easy to change stuff now than later. |
Automatic merge from submit-queue. [DO NOT MERGE] Auto PR to update dependencies of mixerclient This PR will be merged automatically once checks are successful. ```release-note none ```
As per the API design https://docs.google.com/document/d/1Fic1Mgp0W5Sxhd0BxAFOc82DbSYWTsYpi5P-pv8ZjSQ/edit