What is the roadmap?

[ZhiXiao-Lin]

Can you briefly introduce the technology roadmap? I hope to understand your ideas and help you develop this project.

[cardil]

Hi @ZhiXiao-Lin. Thanks for asking.

This project is at this point a PoC. The idea was to check how feasible it would be to build a tool that can create OCI images without any containerization infrastructure, similar to google/ko, but without building of the binaries. In that way, Ocilot could serve as an image building tool for various languages.

That PoC phase went well. I was able to fetch end extract OCI images easily. Adding files on top of the image, and pushing it back, seems straightforward - just a matter of spending some hours on development. However, the PoC had an additional target of checking how viable it would be to package Ocilot parts as wasm modules, so they can be executed from within embedded wasmtime (implements the emerging WASI specification). Running wasm modules on embedded wasmtime, would allow building language-specific build tools like:

• Maven & Gradle plugins (Java)
• Rake tasks (Ruby)
• NPM scripts (JavaScript)
• Setuptools plugins (Python)
• Mage tasks (Go)
• .NET tools (.NET)
• Cargo plugin (Rust) - in this case embedding of wasmtime would not be required as code can be used directly.

Other languages could follow, or use ocilot binary directly.

The intention was that above plugins would only have minimal amount of code. I image only platform-specific code be there, as interfaces to communicate with the Ocilot could be generated from the Protobuf files.

Starting this PoC, I was aware that WASI is in active development, and it is lacking a crucial networking extension. Without the networking, it's impossible for wasm module to connect to remote OCI registry. That's why I intentionally have divided the implementation to couple of modules, so at least some parts of the Ocilot could be reused.

However, it turns out that without ocilot-oci as wasm module, the cost of reimplementing it in a language specific way, would be unjustifiable. Also, apart from the needed WASI networking proposal, I think, this will need async-await support as well.

Taking all the above into consideration, I decided it's too early to fully pursuit all of those projects goals. Completing basic implementation in Rust would be beneficial still. It will allow the people to use the Ocilot as a binary in their build pipeline. At the same time, it would allow me to track progress of WASI, having a real-world application that I like to WASI-fy.

TL;DR: I plan to finish basic implementation in Rust, but it's not a huge priority for me at this point.

Roughly, the implementation will need the following:

• building OCI image layer on top of extracted image
• multi arch support - fetch images for specified archs, and build for each one of them, add manifest list
• proper listing of built images, clearing, proper caching of downloads
• publishing of images
• reading Docker config.json file.

[ZhiXiao-Lin]

This project is very useful. I will use it to replace buildah in my project. I need it to help me pull down the image and extract rootfs without daemon or binary files.