-
Notifications
You must be signed in to change notification settings - Fork 75
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
Convert to accelerated image within a docker container? #136
Comments
@maxwolffe Building overlaybd image can be run in containers under a specified condition. |
Another option is that the overlaybd-ctr could be independent from overlaybd damonse (tcmu and snapshotter), also not require containerd config change: https://github.com/containerd/accelerated-container-image/blob/main/docs/IMAGE_CONVERTOR.md
The use case is that we want to build Overlaybd images which introducing minimal changes to our container image release pipeline. |
@liulanzheng It is possible in principle that a simple pure command line tool without dependency on container engine can do the conversion in a container. And we'd better have such a tool, like @shuaichang has suggested. |
put all in one command line tool requires amount of work. Actually, we can make overlaybd running in containers, even if it doesn't seem formal as other tcmu backstores. But it can be work very well in a controlled environment. |
@shuaichang @maxwolffe We have found a solution to over come the problems that prevents an all-in-one tool for image conversion. We'll try it later. And participation is welcome! |
@lihuiba that’s great to know, it will be very helpful. Any guess when can we try the conversion tool? |
@shuaichang we are focusing on this new approach, but we spent some time exploring. At present, I expect that it will be completed by the end of this month or early next month. |
This is awesome news @liulanzheng ! Any update we can follow or help we can offer? We'd love to help pilot this. |
@maxwolffe A preliminary version will be released in the next one or two days, but it is not perfect for some formats may not support. We will continue to improve and we can improve it together. |
Amazing! Looking forward to it! |
@maxwolffe sorry there's a bad news, we encountered some problems in functional test. We known how solve these problems but this new implementation involves thousand lines of new codes, it takes extra time. |
@maxwolffe please refer to USERSPACE_CONVERTOR It's not yet complete very well, feedbacks and questions are welcome. @yuchen0cc @WaberZhuang are the authors, any problems can state here. |
Great! Thanks @liulanzheng and team! Excited to try it out. |
@liulanzheng - thanks again for your help getting this out. I've started playing with this but encountered an issue, I'm hoping you can help me to debug (happy to open a separate issue if helpful). When I attempt the convertor for an image which I can successfully download (from a private repository), I get a "failed to extract" error.
|
@maxwolffe please set overlaybd-apply log level to 'debug' to get more info.
|
@yuchen0cc - thanks friend. So I make that change (and included my own little change to confirm that the logging change was included). Here is the new output (looks very similar to the previous output):
|
@maxwolffe sorry, the setting is overwrite by the following config in 'imgservice'. So please set the log level in config file instead. The config is stored in '/etc/overlaybd/overlaybd.json' by default. {
"logLevel": 0,
......
} besides the log printed to terminal, more logs are redirected to '/var/log/overlaybd.log' |
@yuchen0cc - thanks for the pointer there. I updated that, encounter the same error, with the same stderr/stdout output. When I look in the overlay.log, I see the following:
Here's my current storage device usage:
When I turn off the debug logs I get the following output (complete output for this run):
Maybe cache is running out of space? This image I'm attempting to convert is 552MB large. |
@maxwolffe the "no space left" means our lsmt block device whose default size is 64 GB per layer. However it also maybe bugs in extfs. |
I ran into the same issue. You can repro it using the image in docker hub |
@northtyphoon many thanks! we'll be managed to figure it out. |
…ir for each layer, remove unused temp file. Signed-off-by: yuchen.cc <[email protected]> containerd#136
@maxwolffe @northtyphoon sorry to keep you waiting so long. We will be continue working on the problems in sparse file... |
Thank you @yuchen0cc |
Recently, we have fixed bugs in sparse file, and made some efforts to speed up converting. |
Is it possible to build overlaybd accelerated images from within a container?
I see that buildkit is experimentally supported (https://github.com/data-accelerator/buildkit) and can be run in a container (https://github.com/data-accelerator/buildkit#containerizing-buildkit), but I also see that accelerator layer is not supported. (https://github.com/data-accelerator/buildkit#containerizing-buildkit).
Is there another path for building or converting overlaybd images within a container?
The text was updated successfully, but these errors were encountered: