-
Notifications
You must be signed in to change notification settings - Fork 159
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: Add project
column to the images
table and refactor ImageRef
related logics
#2707
feat: Add project
column to the images
table and refactor ImageRef
related logics
#2707
Conversation
project
column to the images table and refactoring ImageRef
logicproject
column to the images
table and refactor ImageRef
related logics
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.
- Could we make
ImageRef
also a dataclass? - Could you elaborate why we need a separate
ParsedImageStr
?
I am currently working on refactoring Images to change the format so that
|
be60fc7
to
954ace4
Compare
We need to fix the CI that is currently broken after the PR below is merged. |
d2da906
to
97f826c
Compare
9d94248
to
4425837
Compare
97f826c
to
78477bc
Compare
c04a2d1
to
d042760
Compare
fa39d8d
to
b48fa28
Compare
Overview
project
column to theimages
table.ImageRef
to be a simple type that only holds data (dataclass).project
field. Previously, thename
field mixed theproject
and image names, but nowImageRef.name
only contains the image name, and theproject
value is separately in theImageRef.project
field.Why
Saving the
project
value in the DB is necessary because the string corresponding toproject
may differ depending on the type of container repository, making it impossible to separate theproject
from the image canonical string.The
project
value should also be included in theImageRef
field, andImageRef
should be refactored into a simple struct that only holds data, separated from the existing complex logic of parsing image strings.Refactoring details
This PR performs relatively large-scale refactoring to add a
project
field to theImageRef
corresponding to theImageRow
.ParsedImageStr
typeParsedImageStr
is a namedtuple that represents the parsed result of an image string, containing properties such ascanonical
.ParsedImageStr
type is similar to theImageRef
type, but it cannot distinguish between the project and image name and does not include architecture information, so it does not correspond to a singleImageRow
.ImageRef.parse_image_str()
returns aParsedImageStr
type, which can be used to create anImageRef
. But you can also create anImageRef
instance directly usingImageRef.from_image_str()
.Comparison of
ImageRef.parse_image_str()
with the existingImageRef()
constructorknown_registries
* which contains contextual information about registries, was separately provided and used to parse theimage_str (value)
ImageRef
is now just a simple dataclass, so the parsing logic previously handled by theImageRef
constructor is now handled byImageRef.parse_image_str()
.ImageRef.parse_image_str()
can only accept a single registry as an argument, unlike the existing code, which allows for multiple registries throughknown_registries
.['*']
to theknown_registries
parameter in the original code can be replicated by passing"*"
to the registry argument inImageRef.parse_image_str()
. For more details, please refer to the comments in theImageRef.parse_image_str()
function and thetest_docker.py
test code.ImageIdentifier
typeImageRow
.ImageRow.resolve()
can now be operated usingImageIdentifier
, in addition toImageAlias
andImageRef
.Add
IMAGE_REF
type toExtTypes
ImageRef
type tomsgpack
to enable the exchange ofImageRef
type objects in RPC communication between the managers and agents.Etcs
image_ref
that are not of theImageRef
type (but are actuallystr
).Checklist: (if applicable)
Image.project
column📚 Documentation preview 📚: https://sorna--2707.org.readthedocs.build/en/2707/
📚 Documentation preview 📚: https://sorna-ko--2707.org.readthedocs.build/ko/2707/