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

feat(bentocloud): deployment v2 api client + cli #4335

Merged
merged 3 commits into from Jan 3, 2024

Conversation

Haivilo
Copy link
Contributor

@Haivilo Haivilo commented Dec 13, 2023

What does this PR address?

bentoml.deployment.create(...)
bentoml.deployment.update(...)
bentoml.deployment.apply(...)
bentoml.deployment.get(...)
bentoml.deployment.list(...)
bentoml.deployment.terminate(...)
bentoml.deployment.delete(...)
bentoml deploy .
bentoml deployment update
bentoml deployment get
bentoml deployment list
bentoml deployment terminate
bentoml deployment delete

Before submitting:

@Haivilo Haivilo requested a review from a team as a code owner December 13, 2023 01:55
@Haivilo Haivilo requested review from sauyon and removed request for a team December 13, 2023 01:55
@Haivilo Haivilo marked this pull request as draft December 13, 2023 01:58
@Haivilo Haivilo force-pushed the feat/deployment-client-v2 branch 2 times, most recently from c53ddb9 to b47cd78 Compare December 15, 2023 05:09
@Haivilo Haivilo marked this pull request as ready for review December 18, 2023 04:17
Copy link
Contributor

@frostming frostming left a comment

Choose a reason for hiding this comment

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

What about making get_rest_api_client accept a version parameter instead of accessing via client.v1?

def get_rest_api_client(version = "v2"):
    ...
    return getattr(client, version)

src/bentoml/__init__.py Outdated Show resolved Hide resolved
@Haivilo
Copy link
Contributor Author

Haivilo commented Dec 18, 2023

What about making get_rest_api_client accept a version parameter instead of accessing via client.v1?

def get_rest_api_client(version = "v2"):
    ...
    return getattr(client, version)

I am not sure if we should do this, because some methods use both v1 and v2. If we were to do it this way, then we need to instantiate it in 2 lines instead of 1. Is there any draw back to return the whole client?

client_v1 = get_rest_api_client(version = "v1")
client_v2 = get_rest_api_client(version = "v2")
...

@aarnphm
Copy link
Member

aarnphm commented Dec 18, 2023

What about making get_rest_api_client accept a version parameter instead of accessing via client.v1?

def get_rest_api_client(version = "v2"):
    ...
    return getattr(client, version)

I am not sure if we should do this, because some methods use both v1 and v2. If we were to do it this way, then we need to instantiate it in 2 lines instead of 1. Is there any draw back to return the whole client?

client_v1 = get_rest_api_client(version = "v1")
client_v2 = get_rest_api_client(version = "v2")
...

This get_rest_api_client is internal right?

Why do we need v1 still?

@Haivilo
Copy link
Contributor Author

Haivilo commented Dec 18, 2023

What about making get_rest_api_client accept a version parameter instead of accessing via client.v1?

def get_rest_api_client(version = "v2"):
    ...
    return getattr(client, version)

I am not sure if we should do this, because some methods use both v1 and v2. If we were to do it this way, then we need to instantiate it in 2 lines instead of 1. Is there any draw back to return the whole client?

client_v1 = get_rest_api_client(version = "v1")
client_v2 = get_rest_api_client(version = "v2")
...

This get_rest_api_client is internal right?

Why do we need v1 still?

Only update and create deployment has v2 api. We will be using v1 api for all the rest of the endpoints:

class RestApiClientV2(BaseRestApiClient):
def create_deployment(
self, create_schema: CreateDeploymentSchemaV2
) -> DeploymentFullSchema | None:
url = urljoin(self.endpoint, "/api/v2/deployments")
resp = self.session.post(url, data=schema_to_json(create_schema))
self._check_resp(resp)
return schema_from_json(resp.text, DeploymentFullSchema)
def update_deployment(
self, deployment_name: str, update_schema: UpdateDeploymentSchemaV2
) -> DeploymentFullSchema | None:
url = urljoin(self.endpoint, f"/api/v2/deployments/{deployment_name}")
resp = self.session.post(url, data=schema_to_json(update_schema))
self._check_resp(resp)
return schema_from_json(resp.text, DeploymentFullSchema)

@aarnphm
Copy link
Member

aarnphm commented Dec 18, 2023

What about making get_rest_api_client accept a version parameter instead of accessing via client.v1?

def get_rest_api_client(version = "v2"):
    ...
    return getattr(client, version)

I am not sure if we should do this, because some methods use both v1 and v2. If we were to do it this way, then we need to instantiate it in 2 lines instead of 1. Is there any draw back to return the whole client?

client_v1 = get_rest_api_client(version = "v1")
client_v2 = get_rest_api_client(version = "v2")
...

This get_rest_api_client is internal right?
Why do we need v1 still?

Only update and create deployment has v2 api. We will be using v1 api for all the rest of the endpoints:

class RestApiClientV2(BaseRestApiClient):
def create_deployment(
self, create_schema: CreateDeploymentSchemaV2
) -> DeploymentFullSchema | None:
url = urljoin(self.endpoint, "/api/v2/deployments")
resp = self.session.post(url, data=schema_to_json(create_schema))
self._check_resp(resp)
return schema_from_json(resp.text, DeploymentFullSchema)
def update_deployment(
self, deployment_name: str, update_schema: UpdateDeploymentSchemaV2
) -> DeploymentFullSchema | None:
url = urljoin(self.endpoint, f"/api/v2/deployments/{deployment_name}")
resp = self.session.post(url, data=schema_to_json(update_schema))
self._check_resp(resp)
return schema_from_json(resp.text, DeploymentFullSchema)

Hmm I propose this: for v2 client it would just extends v1. So only update and create deployments is different. Otherwise it will still be the same.

@Haivilo Haivilo requested a review from FogDong December 19, 2023 03:50
@Haivilo
Copy link
Contributor Author

Haivilo commented Dec 19, 2023

Discussed with @aarnphm and @frostming , let's keep using client.v1.xxx and client.v2.xxx since it's internal.

Copy link
Member

@aarnphm aarnphm left a comment

Choose a reason for hiding this comment

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

A few final comments. Then we can get this in

src/bentoml/_internal/cloud/__init__.py Show resolved Hide resolved
src/bentoml/_internal/cloud/client.py Outdated Show resolved Hide resolved
src/bentoml/deployment.py Outdated Show resolved Hide resolved
@Haivilo Haivilo force-pushed the feat/deployment-client-v2 branch 6 times, most recently from d157ccd to 95a0de0 Compare December 27, 2023 08:23
@Haivilo Haivilo force-pushed the feat/deployment-client-v2 branch 4 times, most recently from fde9712 to e56534a Compare December 30, 2023 03:03
@Haivilo Haivilo changed the title wip: feat(bentocloud): deployment v2 api client feat(bentocloud): deployment v2 api client + cli Dec 30, 2023
Copy link
Member

@aarnphm aarnphm left a comment

Choose a reason for hiding this comment

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

Few things.

src/bentoml/_internal/cloud/__init__.py Show resolved Hide resolved
)
# Moved atrributes to __init__ because otherwise it will keep all the log when running SDK.
def __init__(self):
self.log_progress = Progress(TextColumn("{task.description}"))
Copy link
Member

Choose a reason for hiding this comment

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

Note to @aarnphm: Here once migrate to tqdm.

src/bentoml_cli/deployment.py Outdated Show resolved Hide resolved
src/bentoml_cli/deployment.py Show resolved Hide resolved
src/bentoml_cli/deployment.py Show resolved Hide resolved
src/bentoml_cli/deployment.py Show resolved Hide resolved
@Haivilo Haivilo requested a review from aarnphm January 3, 2024 01:05
@aarnphm
Copy link
Member

aarnphm commented Jan 3, 2024

LGTM

Copy link
Member

@aarnphm aarnphm left a comment

Choose a reason for hiding this comment

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

LGTM

@aarnphm aarnphm merged commit a0f5614 into bentoml:1.2 Jan 3, 2024
40 checks passed
frostming pushed a commit that referenced this pull request Jan 17, 2024
* feat: deployment v2 sdk

* feat: cli

* fix: bentoml.cloud.Resource object deprecation
frostming pushed a commit that referenced this pull request Feb 1, 2024
* feat: deployment v2 sdk

* feat: cli

* fix: bentoml.cloud.Resource object deprecation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants