Skip to content

Bacalhau project report 20220425

lukemarsden edited this page Apr 25, 2022 · 1 revision

Last week we started the process of moving Bacalhau/IPCS towards deployment as a production network, similar to IPFS.

There are going to be substantial changes to the prototype codebase to get it to production quality. We decided to do the refactoring incrementally, while adding new features necessary for production, with the goal of keeping the codebase working throughout the changes, and avoiding Second System Syndrome.

User provided docker images

The first feature we are adding to this end is the ability for users to provide their own docker images. This entails ripping out the prototype code for running ipfs inside the user container (because the prototype assumed the user was running the container image we provided, which had IPFS baked into it).

An IPFS sidecar

Instead, we are developing a sidecar approach to running an IPFS sidecar container which provides the ipfs filesystem to other containers on the system that need to consume it. This relies on a container volume propagation mode of rshared, something Kai and I are familiar with dealing with from extensive container storage work previously.

This week we will continue the productionization of the prototype, incrementally, with a goal of getting the system ready for public consumption by the end of May!

A note on WASM

We are hearing early noises from users (via Wes) that a container image interface is desired. Also, our research into being able to provide a FaaS (functions-as-a-service, i.e. Lambda-like UX) interface to e.g. Python in WASM is suggesting that it will only work for a small subset of Python libraries, and so while this approach provides a path to determinism, it may not work very well and may not be what users want!

We plan to provide both a docker-powered container interface and a WASM-powered functions interface for launch. The messaging around containers might be that their execution is nondeterministic and thus not verified. So, we are pushing the choice onto users somewhat: a verified but constrained functions execution environment, or an unverified but unrestricted arbitrary container interface.

Clone this wiki locally