lablup
feat: Improve local type container registry handling
Currently, even local type container registries are constrained by the project value and the name of a non-existent virtual container registry.
This PR removes all unnecessary restrictions, allowing local images to be scanned as they are.
Checklist: (if applicable)
- [x] Milestone metadata specifying the target backport version
[!WARNING] This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite. Learn more
-
#2980
👈 (View in Graphite)
-
#3237
-
#2979
-
#2978
-
main
This stack of pull requests is managed by Graphite. Learn more about stacking.
Is there a reference that can give me the motivation for this work?
@HyeockJinKim Unfortunately, there is no separate reference compiled.
But, as explained in the PR description, when rescanning and using the local images (such as when creating a session), it would be much more intuitive to use only the image name rather than assigning arbitrary registry_name and project name. (Because there is no registry information corresponding to these local images.)
If we decide to apply this PR, creating a migration script to update existing local image records seems necessary so that the Images.image column has the same value as the Images.name column (except tag).
To include the registry_name in the canonical even for local type strings as in the current implementation, a separate container_registry row must be created for each local image with a different registry part.
And even with this approach, images that do not include a registry_name cannot be rescanned at all.
My proposal is to exclude registry_name from the canonical of Local type images.
https://github.com/lablup/backend.ai/pull/2980/files#diff-b2ff25f56c8729a1b42b80c61cfbbfb9ae08f5e9fe8d9675321f4c3f311404b8R586-R588
@achimnol I would appreciate it if you could review this idea. I think it will be helpful for us to implement more general image rescan logic.