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

convertor: support multi-arch images #266

Merged
merged 1 commit into from
Mar 11, 2024

Conversation

WaberZhuang
Copy link
Contributor

@WaberZhuang WaberZhuang commented Feb 28, 2024

What this PR does / why we need it:
Add support for converting multi-arch images.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
#264

Please check the following list:

  • Does the affected code have corresponding tests, e.g. unit test, E2E test?
  • Does this change require a documentation update?
  • Does this introduce breaking changes that would require an announcement or bumping the major version?
  • Do all new files have an appropriate license header?

go.mod Outdated
@@ -10,17 +10,17 @@ require (
github.com/moby/locker v1.0.1
github.com/moby/sys/mountinfo v0.6.2
github.com/opencontainers/go-digest v1.0.0
github.com/opencontainers/image-spec v1.1.0-rc2.0.20221005185240-3a7f492d3f1b
github.com/opencontainers/image-spec v1.1.0-rc5
Copy link
Member

@djdongjin djdongjin Feb 28, 2024

Choose a reason for hiding this comment

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

image-spec 1.1.0 has been release, use v.1.1.0 instead of rc? https://pkg.go.dev/github.com/opencontainers/image-spec@v1.1.0/specs-go/v1

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the heads up, I'll have a look at the differences between the 2 versions.

Comment on lines 127 to 128
// (TODO) platform filter
manifestDescs = append(manifestDescs, index.Manifests...)
Copy link
Member

Choose a reason for hiding this comment

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

it may be possible that an index has another index which has other manifests? maybe good to handle ImageIndex case recursively?

Copy link
Member

Choose a reason for hiding this comment

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

This is in fact explicitly valid according to the oci spec https://github.com/opencontainers/image-spec/blob/f5f87016de46439ccf91b5381cf76faaae2bc28f/image-index.md?plain=1#L46 I doubt its common common though or if wed want to support it in practice.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Anyway, I rewrote a version of the implementation to handle the recursive index.

platform = platforms.Format(*mDesc.Platform)
rctx = log.WithLogger(gctx, log.G(ctx).WithField("platform", platform))
}
workdir := filepath.Join(opt.WorkDir, strings.ReplaceAll(platform, "/", "-"))
Copy link
Member

Choose a reason for hiding this comment

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

Unfortunately, there is no guarantee that there is only one platform type per manifest as weird as that sounds and there is no requirement to include the platform in the index, its even possible to repeat the same manifest. To avoid any possible work folder collisions, we might want to add some additional value to the workdir e.g make it a guid or maybe add the manifest number in the index to the path?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed to "{id}-{platform}-{digest}" format, id is an auto-incrementing key.

var mu sync.Mutex
var targetDescs []v1.Descriptor
g, gctx := errgroup.WithContext(ctx)
for _, _mDesc := range manifestDescs {
Copy link
Member

Choose a reason for hiding this comment

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

Following the introduced logic, we are basically creating an engine per manifest to convert each sub manifest. This introduces some concurrency concerns, especially because each conversion can potentially take up substantial storage space, we may want to add a limit to the number of manifests that can be converted at once and maybe make that configurable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

add --concurrency-limit, default 4.


mu.Lock()
defer mu.Unlock()
targetDescs = append(targetDescs, desc)
Copy link
Member

Choose a reason for hiding this comment

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

Are there any annotations that we could add to denote that the artifacts are streamable ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I made a few changes to keep the artifacts in their original order

@yuchen0cc yuchen0cc added the ok-to-test Pull request is ok to run ci test label Mar 1, 2024
Signed-off-by: zhuangbowei.zbw <zhuangbowei.zbw@alibaba-inc.com>
@yuchen0cc yuchen0cc merged commit 8174392 into containerd:main Mar 11, 2024
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ok-to-test Pull request is ok to run ci test
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants