 Okay, next up we've got a courier who's gonna be talking about lazy distribution of container images. Hi, I'm Akira Suda from entity corporation. I'm a manager of Contraindy and Moby and Moby village. In this talk, I will show how to run containers without waiting for completion of downloading the images. And there are lots of alternative image formats proposed to support this lazy distribution technology. Amongst these formats, Sturgis is getting wide option and it's already adapted by Contraindy and also Potomac. Let's start with the demo. In this demo, I will show a lazy distribution of Docker.io-slash-library-slash-python3.7 image. So the top panel is for legacy and the bottom is for Sturgis. And in this demo, I'm showing Python with just the print hero word. And Sturgis image just took 5.2 seconds for downloading the image and executing print hero word. But the legacy format takes more time. It's still taking time. So it took 26.5 seconds. So Sturgis format is five times faster compared to the legacy format for printing hero word. So let's look into the problems of the current Docker and also image format. Most of Contraindy implementations, including Docker, Moby, Potomac, and Contraindy and quite a bit even singularity conforms to OCI standard format. OCI standard is based on the legacy Docker image format. So the Docker and OCI focus on the legacy compatibility rather than making the technical innovations. So the biggest problem is that it's based on Terraformat, appeared in 1970s, originally for magnetic-type media. So magnetic-type media is shown here as such for one-circles-type media. This is a PDP-elegant mini-computer. So the tape archive doesn't support random access for the obvious reason. So this is not good to fit for five-system images. So the typical archive is composed like this. So you have metadata for the first file at the beginning of the archive and the second file for us. So to mount this archive as a five-system, you need to scan the file for a virtual magnetic tape. If we could have an external index five, we can mount this as a five-system, but this doesn't work for a compressed archive because this doesn't support C-cooperation. And the second problem is that it doesn't support data publication. So the content registry may contain very similar but slightly different images with different versions or with different simple architectures or with different computational files and that's what's ETC. So the turbos of this image are very likely to waste the storage. But this is not a huge deal when you have enough budget for the cloud storage that is used as the backend of the registry. So the most important issue is that the table requires scanning the whole virtual magnetic tape for mounting the archive as a five-system. So in this tool, I focus this issue for the registry distribution. So why do we want a registry distribution? There's already a good scientific paper about this. So according to this paper, only 6.4% of the data is actually used and more than 90% just waste for the actual workload. Here are some expected use cases of a registry distribution. So the registry distribution is the most good for SDK images are used in Docker file. So the SDK images in the Docker file contains some compilers and some libraries and some header files, but most of these headers and libraries are not actually used for actual compilation. And also for Docker files, we don't need to consider for the torrents against registry failures because Docker build is already freaky. So after getting some practice open files with some HTTP error, so you don't need to consider for torrents of the registry failures. There's also good use cases such as functional as a service, because for functional as a service, the search up latency is really important. And we can also use the registry distribution for web applications with a huge number of HTML files and graphic files. And it's also good for Jupyter notebooks with big data samples. And also we can use that whole GNOME KDE desktop in a container. So maybe just real with the era of controllerized Linux desktop. But for these use cases, probably we need to consider for torrents until the image gets 100% charged locally. You can use Kubernetes readiness proof for inspecting the charge status. So three years ago, we did a first attempt, but it failed, so I will show you as a post-mortem story. So our first attempt was that file-grain, which I show in open source summit in North America, it was composed of protobufra index five and content addressable small broad files like this. So this protobufra message contains chat to five, six digest for each of the files and each of the files are content addressable by the chat to five, six digest. But this file-grain format didn't become popular because of incompatibility with legacy table. And there was also a chicken and egg issue. So it's hard to finalize the spec when no implementation exists. And it's also harder to promote implementation when the spec is not finalized. And also we didn't clarify the use case. So we too much focused on data application but data application appeared not so important. I know there was also a huge performance overhead because of the number of small HTTP requests. So the new solution in this year is Stargaze. The Stargaze format is proposed by Brad Fitzpatrick at Google, mostly for accelerating the CI of the Go language project. And it doesn't focus on data application. It only focus on a lazy distribution. The Stargaze format is fully compatible with legacy table format, but slightly different. So the legacy table format, the entire archive is JGIP. But for Stargaze, each of five is JGIP. So the compression granularity is different. And also we have stargaze.index.json at the end of the archive. This index.json has all the metadata for all files in the archive. So we only need the stargaze.index.json for mounting this image. And actual files in the archive can be fetched on demand using HTTP range requests. And the stargaze is being adopted by a severe continental times, including Continuity and Portman. For Continuity, my colleague Kohei Tokunaga as an entity implemented this as Continuity Slap Shutup plugin. And Continuity implementation has more aggressive optimization. For Portman, Joseph Escribano at Red Hat is working on a huge overlay of this plugin for supporting stargaze in Portman. And for Continuity implementation, we have some optimization technology. So we profile actual file access patterns by running an equivalent of Tokunaga. And we reload the file entries in the archive so that ready-to-run files can be prefetched in a single HTTP request. So in this example, we have slash app.py as the entry point. So apparently we need this Python file, so we put this file at the head of the archive. And we also need a Python interpreter, user slash bin slash Python three. And this Python interpreter requires slash lib slash libc.throw. And also we need some Python modules, say user slash lib slash Python three slash blah, blah, blah, slash foo. But we don't need all Python archive. So we only prefetch Python modules that we really need for app.py. And we prefetch these red files in a single HTTP request. Currently, we need to do equivalent of Tokunaga for getting file access patterns. But in future, maybe we can do some static analysis using LDD commands or maybe some machine learning technology. And here are some benchmark results using Drucker Hub. And the continuity host was rotated on easy to rave vision. And for benchmark, we used typical base images with compile-hero world-like workload. So for the Python, the legacy image took more than 26 seconds. And strategies image just need about five seconds. So it's five times faster. So result was similar for ZCC image. Also, the result was similar for Goran image. For Goran image, the result was slightly different. So the legacy image took about 25 seconds. But the staircase without optimization is not so fast. But with optimization, the staircase image becomes much faster. So it's about 12 seconds. So it's two times faster compared to the legacy format. And we are planning to do much more optimizations soon. For implementation, we are planning to parallelize HTTP operations across image areas. This was hard because of the design gap in our quantity-pragment design. But I think we can improve in the coming weeks. And for specifications, we are planning to use ZSTD compression format instead of ZDIP. This was proposed by Giuseppe for mostly for images with a lot of small files. So using ZSTD is not compatible with the current OCI image spec version 1.0.1. But next revision of OCI image spec is likely to support ZSTD as a compression format. So this is compatible with the next version of OCI image spec. And we are also planning to integrate Sturgis into our build kit. And we plan to support protesting Sturgis images using build kit. And also we will support consuming Sturgis images as our base images of Docker files that appears from instructions of Docker files. And also there are other alternative formats that support Ray's distribution. For example, CERN-VMFIS is already widely deployed in CERN and their friends' environments. But the CERN-VMFIS format is not compatible with Ray's OCI tables. And there's already implementation for CERN-VMFIS. And there's also a proposal of what is called OCI version 2. This is proposed by Alec Sassari at Susie, but this is not an official OCI format at this moment. And it's also not compatible with OCI version 1 tables. The OCI version 2 will focus on data application using RESTIC algorithm. So it's very different from Sturgis format. And there's already work in progress, implementation for UMOTI, image manipulation too. But as far as I know, there is no runtime implementation exist for this OCI version 2. And there's also IPS-CS proposed by Edogaree at Netflix. IPS-CS format is built on IPFS which is P2P REST, P2P STRAZE. This is not compatible with OCI tables, but we already have implementation for CERN-VMFIS. And also Microsoft Azure built something similar using assembly protocol and BSD images, but this project is not free software at this moment. So to recap my talk, there are lots of alternative image formats are proposed for REST distribution. But compatibility is really important. And Sturgis is getting wider adoption. It's compatible with legacy OCI machines. And it's already adopted by Contra D and also by Kotman. And for Contra D implementation, we support prefacing optimization. So our implementation is available at this GitHub repo. This is currently under my colleague's GitHub account, but this is expected to be moved under github.com slash Contra D soon. And we request for comments such as village and imperative use cases and how we can do more efficient optimization. Thanks. Questions? Hi, thank you for the talk. Is it, do I understand correctly that only the needed files will be downloaded? Sorry, just to be gradually. Do I understand correctly that only the needed files will be downloaded? So not the full image will be downloaded on the? Oh yeah, so not full images downloaded. Only files that actually exist is downloaded. Okay, cool. Hello, questions? Up. Oh, no. I didn't understand if it is already integrated with the build kit or not. So not integrated into build kit, we are planning, so please stay tuned. So please wait. So who creates the Stargaze index JSON file and how many container images and any given? I'm sorry, JSON what? The Stargaze JSON index file, who creates the build kit tool? Currently we have some converter tool in our repository. So please see, ktoc-stratgate-slapshooter. We have some converter commands in this repo. So when you say wide adoption, I just want to know percentage of images that have the Stargaze JSON file already today. So the JSON file is generated by converter tool in this repo. Does that answer your question? And last question, any distribution spec changes that you expect for this to have wide adoption? No change. Okay. So it's even compatible with Docker Hub. So actually we use Docker Hub hosted by Docker Ink without any modification. One last question if there's any. Uh-uh. Think we're good. Thank you.