git rebase is a very useful construct in source control management, as it allows you to re-apply your changes atop a different branch of the same repository. While this concept transitions perfectly to container management (updating a container could be as easy as a docker rebase), and the Docker client is inspired by the git semantics, Docker has no such feature (in fact, Solomon Hykes used rebase and merge as examples of things "that we don't want"). Currently, zypper-docker works by applying an updated layer on top of an existing image. While this does work quite well, it separates the process of updating the base image and updating all of your derivative images (you need to re-download new packages for each derivative image).
So, this project will be working on implementing something likegit rebase for Docker images. There are several issues with this, mainly involving the fact that we are rebasing binaries and not source code, so merge conflicts will probably be quite messy. But it should be possible to implement some form of simple rebase method (which will essentially fall back to docker build in the worst case, which is what you were going to run anyway). By maximising the reuse of the existing image layers, it should be possible to reduce build times quite significantly.
Currently, dealing with forkbombs and similar issues with Docker and runC is not very nice (you have to set a global limit for all Docker processes or you have to limit kernel memory which isn't very practical). I'm going to work on getting some [patches] merged into runC and Docker to enable PIDs support for Docker.
In many cases, people want to start containers on a system where the administrator is not happy about granting privileges to users or installing any new software. For example, when I was a researcher and wanted to run Python 3 on a computing cluster it was not possible to get the administrator to install Docker or Python 3.
In recent Linux kernels, it has been possible to create containers without any privileges. All that's missing is a container runtime that allows you to do this. LXC is close but falls short (it requires certain privileged processes and PAM modules for everything to work).
Currently the Open Container Initiative doesn't specify a distribution protocol or system, and the current "standard" format is the Docker registry protocol. Aside from technical reservations with Docker registry, it is also not an OCI-compliant system and will require a lot of work to integrate it into all of the openSUSE/SUSE tooling.
So, a very insane idea I came up with is to convert OCI images to RPMs and then distribute them as simple RPMs. The idea would be to use capabilities (Provides: oci(...)) to implement the different names of images and then also the dependency graph of blobs (which would naturally be de-duplicated).
Currently the main complaint people have about OCI tooling is the lack of a transition from Docker to OCI. With umoci you have a lot of low-level image configuration abilities, and skopeo and runC cover the other major parts of the picture, but you need something to tie them together.
I'm not going to be implementing YAWAR (Yet Another Wrapper Around Runc). It's just going to be a single script that can take a Dockerfile and create an OCI image that is basically the same as the Docker image you would get -- with the big difference being that you didn't need Docker and everything used the OCI. The other cool benefit of this is that you could build images without privileges (since rootless containers now exist in runC and in umoci).
The plan is to implement a safe path resolution library for Linux to avoid the plentiful numbers of security vulnerabilities that have been seen in the wild related to path resolution race conditions and various other attacks. I've been working on kernel-space solutions but even if they were merged, it is difficult to use them safely directly. So this library intends to provide simple wrappers that everyone can use.
Very often people find themselves wanting to store secrets in a way that either they can recover even if (for instance) their house burns down, or allow friends and family to recover if they pass away. Existing solutions to this problem are:
* Too complicated to use for ordinary people.