-
Notifications
You must be signed in to change notification settings - Fork 431
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
Added Python API server client #1561
Conversation
@z103cb, @tedhtchang, @astefanutti please take a look cc @kevin85421 |
@anishasthana pls take a look if you have time |
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.
Overall this is looking good, but I am not a python expert.
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 think a lot of data object code could be trimmed using pydantic. Is there a constraint on bringing in new external dependencies?
The client code should ideally wrap the HTTP calls using the requests library in another method so that when a refactoring of http calls to add authentication is needed, the change can be done in a single place.
self.annotations = annotations | ||
self.labels = labels | ||
|
||
def to_string(self) -> str: |
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.
Wouldn't it be simpler to use something like pydantic for these dataclasses? Then you would get the to_string and to_dict methods for free.
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.
Not really, If you notice I do names transformations between classes and dict. I want to be able to use different names.
Additionally I am separating input and output params in to_dict to ensure the proper input. Finally I do not think pydantic can do complex back transformations from dict
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.
Usage of pydantic will require custom serializers, so its basically the same amount of code if not more
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 all the transformations you need are between snake case and camel case it's not that much code: https://medium.com/analytics-vidhya/camel-case-models-with-fast-api-and-pydantic-5a8acb6c0eee
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.
Lots of boilerplate here...
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 was able to verify the PR by running the tests cases. We may need a little more instructions in the README.
Signed-off-by: Boris Lublinsky <[email protected]>
…_python # Conflicts: # apiserver/Volumes.md # clients/python-apiserver-client/README.md # clients/python-apiserver-client/python_apiserver_client/kuberay_apis.py # proto/go_client/cluster.pb.go # proto/go_client/config.pb.go
@kevin85421 I think we are good with this and can merge |
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.
Since the benefit of removing some code lines versus the cost including a new dependency like pydantic is not clear, I think this is fine.
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.
Suggestions for spelling grammar, etc., but I also asked if much of the more "boilerplate" part of this API could be replaced by some standard Python for K8s. It seems that many concepts here are not specific to Ray or KubeRay.
clients/python-apiserver-client/python_apiserver_client/kuberay_apis.py
Outdated
Show resolved
Hide resolved
clients/python-apiserver-client/python_apiserver_client/params/environmentvariables.py
Show resolved
Hide resolved
clients/python-apiserver-client/python_apiserver_client/params/headnode.py
Show resolved
Hide resolved
self.annotations = annotations | ||
self.labels = labels | ||
|
||
def to_string(self) -> str: |
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.
Lots of boilerplate here...
clients/python-apiserver-client/python_apiserver_client/params/templates.py
Show resolved
Hide resolved
clients/python-apiserver-client/python_apiserver_client/params/volumes.py
Show resolved
Hide resolved
Do not confuse Python APIs with Go implementation, which is using standard Go k8 APIs |
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.
All tests seem to pass. One spelling fix left over. I think in a separate PR we may add the unit test to the apiserver e2e test.
@kevin85421 There are 3 approvals already, lets merge it |
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.
Stamp
Why are these changes needed?
The current Python client is k8-based. This new Python client requires less k8 knowledge from the user and thus lowers the entry barrier for Python developers to use the operator.
Additionally, it cleans up some of the current definitions of the API server
Related issue number
Checks