-
Notifications
You must be signed in to change notification settings - Fork 186
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
feat: Add services
registration API to Client
#340
Conversation
self.items.pop(service_name) | ||
|
||
|
||
class Core(Model): |
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.
For now, core
only has services
-- hypothetically, what else do you think would go here in the future? 👀
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.
Mainly sessions
. Basically I'm moving under core
all the client capabilities needed to talk to the ControlPlane.
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.
gotcha
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 hope is we can direct users towards two directions: apiserver
(managed deployments) and core
(manual deployments) to map the user stories we have in the docs.
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.
Looks great! Love the test cleanup
Part of #335
client.core.services
Also in this PR:
timeout
to the client every single request. It can still be passed if one needs a custom value.conftest.py
to reduce duplicationscope=session
so every e2e function has a fresh control plane to test