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

ModelConfig is ModelVersion! #2044

Merged

Conversation

avishniakov
Copy link
Contributor

@avishniakov avishniakov commented Nov 13, 2023

Describe changes

This is a big refactoring PR containing many renames and breaking changes. The ultimate goal was to bring a simplified user-interface experience, so once ModelVersion is configured in @pipeline or @step it will travel into all other user-facing places: step context, client, etc.

[BREKING CHANGES]

  1. ModelConfig -> ModelVersion
  2. @pipeline(model_config=...) -> @pipeline(model_version=...)
  3. Config YAML: model_config -> model_version
  4. Client methods create_model_version, get_model_version and update_model_version now return ModelVersion
  5. get_step_context().model_version now return ModelVersion
  6. Included here renaming of linked artifacts asmodel_objects>model_artifacts, artifacts>data_artifacts and deployments>endpoint_artifacts in CLI and other places in code.
  7. Previously public methods of response like get_or_create_model_version and get_or_create_model are now private and called under the hood of other functions, so meant to be non-user-facing going forward
  8. ArtifactConfig -> DataArtifactConfig
  9. DeploymentArtifactConfig -> EndpointArtifactConfig
  10. Client methods for Model and ModelVersion were significantly reworked from input args PoV
  11. Sunset of running model versions and surrounding complexity for users. Now if the version is None in model_version a new model version will get created and shared across all other model_version requests inside the same run.
  12. Using DataArtifactConfig and others are no longer working with only model_name - model_version needs to be fed along. In case of misuse, a clear RuntimeError will be raised. These objects can still be used without model_name and model_version to get context from the step.

BUGFIXES

  1. Prevent the creation of versions using reserved names, which happened before, if the "training" pipeline was calling ModelVersion(...,version="staging") in some steps
  2. Properly refresh the template, now it just overwrites/appends files, but not removing old ones, so E2E is a bit of a mess. 9ad0778

SIDE CHANGES

  1. ModelVersion is now equipped with extra public methods, which I find useful. Have a look, if something is missing in your opinion.

Incoming templates PR: zenml-io/template-e2e-batch#19

Pre-requisites

Please ensure you have done the following:

  • I have read the CONTRIBUTING.md document.
  • If my change requires a change to docs, I have updated the documentation accordingly.
  • If I have added an integration, I have updated the integrations table and the corresponding website section.
  • I have added tests to cover my changes.
  • I have based my new branch on develop and the open PR is targeting develop. If your branch wasn't based on develop read Contribution guide on rebasing branch to develop.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Other (add details above)

@github-actions github-actions bot added internal To filter out internal PRs and issues enhancement New feature or request labels Nov 13, 2023
@avishniakov avishniakov changed the base branch from main to develop November 13, 2023 13:43
@avishniakov avishniakov marked this pull request as ready for review November 13, 2023 13:43
Copy link
Contributor

@fa9r fa9r left a comment

Choose a reason for hiding this comment

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

Overall changes look good, just needs a bit more polish before merging 👍

@@ -375,7 +368,7 @@ def list_model_versions(model_name_or_id: str, **kwargs: Any) -> None:
**kwargs: Keyword arguments to filter models.
"""
model_id = Client().get_model(model_name_or_id=model_name_or_id).id
model_versions = Client().list_model_versions(
model_versions = Client().zen_store.list_model_versions(
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are we bypassing the client method here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because I need the response model back, not ModelVersion.

Copy link
Contributor

Choose a reason for hiding this comment

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

As suggested in the other comment - the Client should return the response model anyway if we want to be consistent with the current Client interface, so I guess this would also solve this issue then?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Prefer to keep it as is, no one even knows about zenml.models.model_models.ModelVersionResponseModel thing - it is too internal to be a concerning, in my opinion.

src/zenml/cli/model.py Outdated Show resolved Hide resolved
src/zenml/cli/model.py Outdated Show resolved Hide resolved
src/zenml/cli/model.py Outdated Show resolved Hide resolved
src/zenml/client.py Outdated Show resolved Hide resolved
src/zenml/steps/step_decorator.py Outdated Show resolved Hide resolved
src/zenml/model/model_version.py Outdated Show resolved Hide resolved
src/zenml/model/model_version.py Outdated Show resolved Hide resolved
src/zenml/model/model_version.py Outdated Show resolved Hide resolved
src/zenml/model/model_version.py Show resolved Hide resolved
@fa9r fa9r mentioned this pull request Nov 15, 2023
9 tasks
@avishniakov avishniakov requested a review from fa9r November 15, 2023 15:51
Copy link
Contributor

E2E template updates in examples/e2e have been pushed.

Copy link
Contributor

@fa9r fa9r left a comment

Choose a reason for hiding this comment

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

Only major issue I see is that the Client methods are still inconsistent with other entities, other than that it looks ready to merge from my side

src/zenml/client.py Outdated Show resolved Hide resolved
avishniakov and others added 9 commits November 16, 2023 11:06
…' of https://github.com/zenml-io/zenml into feature/OSS-2609-OSS-2575-model-config-is-model-version
* Moved model versions to their own root route

* Fix the delete endpoint

* Fixed smaller mistakes

* Fixed for Client as well

* Fixed lint errors

* More linting

* More linting

* More tiny fixes

* Update src/zenml/zen_server/routers/model_versions_endpoints.py

Co-authored-by: Andrei Vishniakov <[email protected]>

* More linting

* Fixed tests and solved conflicts

* Fixed linting

* Fixed more tests

* Further refactoring

* Added raises section

* Fix one failing test

* Take "latest" stage into account

* Reformatted

* Standardize use of list response

* Rewrote some tests

* Add clien tests

* Fixed spelling

* Tested to work with e2e pipeline

* Ugly fixes to get response models in the CLI

* Auto-update of E2E template

* Access ModelVersionResponseModels in Client again

* Another small fix

* Linted

---------

Co-authored-by: Andrei Vishniakov <[email protected]>
Co-authored-by: GitHub Actions <[email protected]>
Copy link
Contributor

E2E template updates in examples/e2e have been pushed.

@avishniakov avishniakov requested a review from fa9r November 16, 2023 20:46
@avishniakov
Copy link
Contributor Author

@fa9r , any vetos merging this? Otherwise, I'll merge.

Copy link
Contributor

@fa9r fa9r left a comment

Choose a reason for hiding this comment

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

I would still suggest to change create / get / update to return ModelVersionResponseModel again, otherwise LGTM

stage: Optional[Union[str, ModelStages]] = None,
force: bool = False,
name: Optional[str] = None,
) -> "ModelVersion":
Copy link
Contributor

Choose a reason for hiding this comment

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

Still not a fan of this returning ModelVersion instead of ModelVersionResponseModel

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Let's proceed like this then:

  • I will merge this one to unblock others (including you with rebasing your mega-branch).
  • Spin a feedback loop on Discord to clarify what we should return and if we should stick to responses here.
  • If we decide to use responses - I'll raise a separate ticket for that purpose.

@avishniakov avishniakov merged commit 3f06da9 into develop Nov 17, 2023
4 of 21 checks passed
@avishniakov avishniakov deleted the feature/OSS-2609-OSS-2575-model-config-is-model-version branch November 17, 2023 08:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change enhancement New feature or request internal To filter out internal PRs and issues
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants