Skip to content
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

Merged
merged 28 commits into from
Nov 1, 2023

Conversation

blublinsky
Copy link
Contributor

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

  • [x ] I've made sure the tests are passing.
  • Testing Strategy
    • [x ] Unit tests
    • Manual tests
    • This PR is not tested :(

@blublinsky
Copy link
Contributor Author

@z103cb, @tedhtchang, @astefanutti please take a look

cc @kevin85421

clients/__init__.py Outdated Show resolved Hide resolved
clients/__init__.py Outdated Show resolved Hide resolved
@blublinsky
Copy link
Contributor Author

@anishasthana pls take a look if you have time

Copy link
Contributor

@z103cb z103cb left a 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.

Copy link

@maxdebayser maxdebayser left a 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:

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.

Copy link
Contributor Author

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

Copy link
Contributor Author

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

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

Choose a reason for hiding this comment

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

Lots of boilerplate here...

Copy link
Contributor

@tedhtchang tedhtchang left a 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.

clients/python-apiserver-client/README.md Outdated Show resolved Hide resolved
clients/python-apiserver-client/README.md Outdated Show resolved Hide resolved
clients/python-apiserver-client/README.md Outdated Show resolved Hide resolved
clients/python-apiserver-client/README.md Outdated Show resolved Hide resolved
clients/python-apiserver-client/README.md Show resolved Hide resolved
clients/python-apiserver-client/README.md Show resolved Hide resolved
…_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
@blublinsky
Copy link
Contributor Author

@kevin85421 I think we are good with this and can merge

Copy link

@maxdebayser maxdebayser left a 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.

Copy link

@deanwampler deanwampler left a 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.

apiserver/pkg/model/volumes_test.go Show resolved Hide resolved
clients/python-apiserver-client/README.md Outdated Show resolved Hide resolved
clients/python-apiserver-client/README.md Outdated Show resolved Hide resolved
clients/python-apiserver-client/README.md Outdated Show resolved Hide resolved
self.annotations = annotations
self.labels = labels

def to_string(self) -> str:

Choose a reason for hiding this comment

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

Lots of boilerplate here...

@blublinsky
Copy link
Contributor Author

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.

Do not confuse Python APIs with Go implementation, which is using standard Go k8 APIs

Copy link
Contributor

@tedhtchang tedhtchang left a 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.

@blublinsky
Copy link
Contributor Author

@kevin85421 There are 3 approvals already, lets merge it

@kevin85421 kevin85421 self-assigned this Nov 1, 2023
@kevin85421 kevin85421 added the 1.0 label Nov 1, 2023
Copy link
Member

@kevin85421 kevin85421 left a comment

Choose a reason for hiding this comment

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

Stamp

@kevin85421 kevin85421 merged commit 1f728c5 into ray-project:master Nov 1, 2023
22 of 23 checks passed
@blublinsky blublinsky deleted the apiserver_python branch November 2, 2023 12:17
kevin85421 pushed a commit to kevin85421/kuberay that referenced this pull request Nov 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants