Proposing new ostreedev/ Rust repositories: ostree-ext and ostree-container

["Colin Walters" <walters verbum org>]

Hi, I'd like to propose a new Rust-oriented model for ostree.  As someone who really cares about the 
integrity of your root filesystem, the Rust programming language calls to me at a deep level.   We've tried 
in the past to add a hard dependency on Rust (xref 
https://mail.gnome.org/archives/ostree-list/2018-December/msg00021.html ) but got pushback, and in fact in 
preparation for this proposal the minimal Rust option in libostree was removed: 
https://github.com/ostreedev/ostree/pull/2306

First: In this proposal, everything that exists in the C library will stay the same; nothing will break or be 
removed.  This proposal only *adds* functionality but changes the emphasis of future development.

The proposal is basically (at least) this layering:

 - github.com/ostreedev/ostree: introspectable C library exists as it does today in ostreedev/ostree (there's 
also the /usr/bin/ostree CLI; will get back to that in a bit)
 - crates.io/crates/ostree: Rust bindings for libostree as it exists today (at 
https://gitlab.com/fkrull/ostree-rs)
 - github.com/ostreedev/ostree-ext: A new repository moved from https://github.com/cgwalters/ostree-ext/
 - github.com/cgwalters/ostree-container: A new repository migrated from 
https://github.com/cgwalters/ostree-container

Projects like rpm-ostree and other OS update mechanisms would be encouraged to use the Rust libraries.

Effectively the focus of "ostree" would become the ostree-ext crate.

There's two new repositories there; what do they do?  The first important bit here is 
https://github.com/cgwalters/ostree-ext/#module-tar-tar-exportimport
which effectively adds a new API to *losslessly* import/export ostree commits to tar archives.  The goal here 
is that we e.g. have the exact commit object and metadata and so can still do e.g. GPG validation on import.  
(See https://github.com/cgwalters/ostree-ext/issues/2 )

There's also a new diff API in ostree-ext.

I'd like to drain some of the rpm-ostree `apply-live` code here too, etc.

OK now getting a bit more interesting, as everyone knows, OCI/Docker containers are just layers of tarballs.  
We now have a better tar import/export format, so ostree-container is a crate that adds a thin wrapper on top 
to do import/export to OCI/Docker containers.

For example right now you can run e.g.
```
$ podman run --entrypoint bash --rm -ti quay.io/cgwalters/fcos
```
(Or run in Kube/etc.)

That container image was generated via:
```
$ ostree-container build --repo=/var/srv/walters/builds/fcos/tmp/repo --ref 
fedora/x86_64/coreos/testing-devel --oci-dir=/var/srv/walters/builds/fcos/tmp/ostree-oci
$ skopeo copy oci:/var/srv/walters/builds/fcos/tmp/ostree-oci docker://quay.io/cgwalters/fcos
```

(Where the ostree repo /var/srv/walters/builds/fcos/tmp/repo is a coreos-assembler bit, and yes with a bit 
more work we can support directly pushing to a registry)

But more interesting: a project like rpm-ostree could use the ostree-container API to support natively 
pulling and updating from that container image.

With this code we directly stream the tar archive as we download it and import it into the repository, which 
is a *much* better model that e.g. what we do in e.g. OpenShift right now of shipping an archive mode 
repository inside a container.

There's a lot more in the TODO list around ostree-container; in particular around supporting running them as 
a webserver that exports the repo.  If we further support including static deltas as a derived layer from one 
of these containers, then container images can be a good way to manage "snapshots" of repositories, and 
sneakernet/mirror them around.

===

Alternative: rename ostree-rs to "ostree-rs-binding" or so, and then have crates.io/crates/ostree be what is 
now ostree-ext?  

It may also make sense to fold ostree-container into the ostree-ext crate (under a feature flag, since it has 
nontrivial new dependencies).

===

Future of the /usr/bin/ostree CLI: I'd like to support having the `ostree-ext` crate own/replace the 
`/usr/bin/ostree` binary.  Or perhaps ostree-ext installs "extension CLIs" like 
`/usr/lib/ostree/export-commit` and `/usr/lib/ostree/import-commit` and the CLI learns how to do a git-like 
model of mapping that to `ostree export-commit`?

===

This is all a proposal; I plan to continue developing the ostree-ext code and eventually publish to 
crates.io, but what do you all think?