Skip to content
This repository has been archived by the owner on Jan 19, 2023. It is now read-only.

Expose client state as an interface from service #2325

Conversation

xtreme-vikram-yadav
Copy link
Contributor

@xtreme-vikram-yadav xtreme-vikram-yadav commented Apr 13, 2021

What this PR does / why we need it: This PR introduces client state as an interface to make it easy for plugin authors writing tests.

Which issue(s) this PR fixes

Special notes for your reviewer:

Some design decisions:

  • client state is duplicated for plugins and octant. With duplication comes the benefits of not having custom JSON handlers and both copies can now be managed and injected separately within plugins and octant core which provides better control.
  • Plugins have access control over the state as the duplicated state is closer to plugins.

@ftovaro
Copy link
Contributor

ftovaro commented Apr 13, 2021

So if a I understand correctly what you did here, you created some methods to access the attributes of the ClientState in order to allow plugins authors to access those attributes without exposing the ClientState itself, right?

@wwitzel3
Copy link
Contributor

Tom looked at this and was still having trouble because Filter type is internal. I think we need to lift that up as well.

@xtreme-vikram-yadav
Copy link
Contributor Author

xtreme-vikram-yadav commented Apr 13, 2021

Tom looked at this and was still having trouble because Filter type is internal. I think we need to lift that up as well.

Ah right. I'll fix it.

@GuessWhoSamFoo GuessWhoSamFoo merged commit aeb1cfc into vmware-archive:master Apr 22, 2021
@xtreme-vikram-yadav xtreme-vikram-yadav deleted the client-state-interface branch April 22, 2021 19:44
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ClientState uses a private struct
4 participants