How we now use OSTree for Fedora CoreOS, and OpenShift 4

["Colin Walters" <walters verbum org>]

As of lately, I and a number of other people contributing to libostree are part of the CoreOS/OpenShift group 
at Red Hat.

I wanted to provide a few links with some background for how we're using OSTree as part of this:

https://blog.verbum.org/2019/06/04/openshift-4-streamlining-rhel-as-kubernetes-native-os/
https://github.com/openshift/machine-config-operator/blob/master/docs/OSUpgrades.md

Particularly for RHEL CoreOS, we've made OSTree fairly "under the hood" - we ship an OSTree repo inside a 
(Docker-style) container image, so that admins only have one type of thing to mirror.

Fedora CoreOS exposes it a bit more - there's been some interesting work there we've adapted from Container 
Linux ideas - see https://github.com/coreos/zincati/ which currently drives rpm-ostree. 

For RHEL CoreOS it's fairly hidden - and I've been working on a lot of higher level things.  But I want to 
emphasize that for us libostree is a foundational piece, and while development has slowed down some (I know 
sometimes patches have stalled in review, sorry about that; and will try to fix that!), our commitment level 
to libostree is only increasing.  For example, there's been work to ensure that ostree works on s390x 
mainframe hardware.

And at the same time, as I've said before, I'd like to continue to retain the "cross-distribution" flavor 
that libostree has today; in particular being used in OpenEmbedded, Debian, as well as Fedora derivatives.  
So I don't expect any changes there.

Working on a new release now; just wanted to give some quick background on my current thoughts while waiting 
for it to churn through CI =)