Skip to content

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

Merged
merged 4 commits into from
Mar 15, 2018

Conversation

guptasu
Copy link
Contributor

@guptasu guptasu commented Mar 13, 2018

@googlebot googlebot added the cla: yes Set by the Google CLA bot to indicate the author of a PR has signed the Google CLA. label Mar 13, 2018
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
Copy link
Contributor

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.

Copy link
Contributor Author

@guptasu guptasu Mar 14, 2018

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.

  1. InfrastructureIntegration ?
  2. InfrastructureIntegrationBackend ?
  3. IstioIntegration ?
  4. 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

Copy link
Contributor Author

@guptasu guptasu Mar 14, 2018

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.

  1. InfrastructureIntegration ?
  2. InfrastructureIntegrationBackend ?
  3. IstioIntegration ?
  4. 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

retrieve

Copy link
Contributor Author

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);
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

supposed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

D

@guptasu guptasu force-pushed the oopadapterservice branch from 420b77a to 27126f5 Compare March 14, 2018 19:08
Copy link
Contributor Author

@guptasu guptasu left a 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
Copy link
Contributor Author

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);
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

@guptasu guptasu Mar 14, 2018

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.

  1. InfrastructureIntegration ?
  2. InfrastructureIntegrationBackend ?
  3. IstioIntegration ?
  4. 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 ?

@geeknoid
Copy link
Contributor

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.

Copy link
Contributor

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe rename the file?

@guptasu
Copy link
Contributor Author

guptasu commented Mar 14, 2018

@mandarjog over to you now for second lgtm. PTAL.

@guptasu
Copy link
Contributor Author

guptasu commented Mar 15, 2018

@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.

@guptasu guptasu merged commit 88ec95d into istio:master Mar 15, 2018
@guptasu guptasu deleted the oopadapterservice branch March 15, 2018 20:48
@guptasu
Copy link
Contributor Author

guptasu commented Mar 21, 2018

@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.

incfly pushed a commit to incfly/api that referenced this pull request Jun 13, 2018
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
```
nacx pushed a commit to nacx/api that referenced this pull request Feb 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes Set by the Google CLA bot to indicate the author of a PR has signed the Google CLA.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants