-
Notifications
You must be signed in to change notification settings - Fork 467
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
Artifact Version Table + Artifact Tagging #2081
Conversation
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.
LGTM from my side, assuming tests pass.
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.
As discussed, there are a few changes we should make for RBAC to work:
- Add a new
ResourceType.ARTIFACT_VERSION
- Update the
create
,update
anddelete
endpoints for artifact versions to use this resource type - Update the
read
/list
endpoints to use the parent artifact instead to verify whether someone can view a specific version - Update the functions
get_surrogate_permission_model_for_model(...)
andget_resource_type_for_model(...)
inzenml.zen_server.rbac.utils.py
to also handle artifact versions
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.
RBAC part LGTM
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.
Great changes. The concepts of Models and Artifacts seem to be much more similar now. Left a few comments, hope it helps!
@@ -498,6 +503,7 @@ def get_resource_type_for_model( | |||
SecretResponseModel: ResourceType.SECRET, | |||
ModelResponseModel: ResourceType.MODEL, | |||
ArtifactResponse: ResourceType.ARTIFACT, | |||
ArtifactVersionResponse: ResourceType.ARTIFACT_VERSION, |
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.
As far as I can see, artifacts bear a lot of similarities to models in terms of their implementation. As model versions depend on models when it comes to RBAC, artifact versions also depend on artifacts.
Due to this, in the RBAC PR, model versions were left out of this mapping. Was there a different reason why we had to include them 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.
ArtifactVisualizationRequest=ArtifactVisualizationRequest, | ||
) | ||
ArtifactResponseBody.update_forward_refs( | ||
ArtifactVersionResponseBody.update_forward_refs( |
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.
ArtifactVersionResponseBody
s also have ArtifactResponse
s, right? I am surprised that this is not failing due to a forward reference issue.
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.
AFAIK a forward ref is only created if you specify your field type as a string, e.g.
class A(BaseModel):
b: "OtherModel" = ...
However, in the artifact version we import the ArtifactResponse
outside of type-checking and use the full type:
from zenml.models.v2.core.artifact import ArtifactResponse
class ArtifactVersionResponseBody(WorkspaceScopedResponseBody):
artifact: ArtifactResponse = ...
So ArtifactVersionResponseBody.artifact
should not be a forward ref if I understand it right.
Maybe @schustmi can confirm?
@@ -33,12 +33,12 @@ | |||
|
|||
|
|||
def link_step_artifacts_to_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.
Should we rename this to link_step_artifact_versions_to_model
as well?
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.
We could do, no strong opinion against it
src/zenml/zen_stores/migrations/versions/a91762e6be36_artifact_version_table.py
Outdated
Show resolved
Hide resolved
@@ -0,0 +1,228 @@ | |||
"""Artifact Version Table [a91762e6be36]. |
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 would really recommend testing this against different scenarios as it is a significant migration IMO.
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.
Yeah agreed, so far I tested the following scenarios:
- SQLite initialization from scratch
- SQLite upgrade from 0.50.0 with existing artifacts
- MySQL initialization from scratch
- MySQL initialization from 0.50.0 with existing artifacts
Any other case I should test?
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.
In general, I can't think of a different test.
However, In my experience, the migration failures mostly stem from (sort of) edge cases on various versions way before 0.50.0 or so. If there is such a case, (for instance where a specific field of the artifact can be possibly null), I would try to recreate this scenario and test that as well.
Describe changes
I split the
artifact
table intoartifact
andartifact_version
so we can assign a separate set of tags to artifacts themselves.Accordingly, I adjusted CLI, Client, models, ZenStores, and API endpoints to now have separate methods and representations for artifacts and artifact versions.
In particular, artifacts now support the following CLI commands:
Other changes:
zenml artifact prune
now deletes all unused artifacts and artifact versionszenml artifact delete
was removed since deleting artifacts manually is too complex and error-prone to be exposed to users nowPre-requisites
Please ensure you have done the following:
develop
and the open PR is targetingdevelop
. If your branch wasn't based on develop read Contribution guide on rebasing branch to develop.Types of changes