composing/shipping OSTree trees

[Colin Walters]

Hi all,

I wanted to talk about the process for composing and shipping OSTree 
trees. At a high level as far as I understand it there are two efforts:

1) Make the current "Fedora Atomic Initative" tree composes slightly
   more production. This would still just be targeting rawhide, not
   stable releases.
   We don't have to mirror the trees to all of the mirrors, perhaps
   just a subset.

2) A stable release of *just* the Fedora Cloud Docker Host tree.  

Now implementation wise, there are a number of parts:

* rpm-ostree treecompose
  - This is basically another "yum --installroot" variant, like Lorax, 
    etc. The major conceptual difference is that it produces content 
that
    client systems can use as an online upgrade source *post* 
installation.
  - Should this be a Koji plugin? Or should the treecompose be a 
    separate server?
* Repository structure:
  - Do we have one OSTree repository specifically for the Fedora Cloud
    Docker Host, or is it merged with the generic FAI repository?
* GPG signing of trees
  - Is supported, but needs integration with rel-eng
* Mirroring/deltas
  - Right now the OSTree format is good for incremental continuous
    deployment. If you're a user tracking Rawhide daily, I think OSTree
    is pretty much a perfect fit. Downloading just the changed files
    one HTTP request at a time is just fine.

    However it's not so great for major release updates. See:
    https://mail.gnome.org/archives/ostree-list/2013-July/msg00005.html
    https://bugzilla.gnome.org/show_bug.cgi?id=721799
    The executive summary is it's about 80% done. It's quite possible
    that it will be finished by GA. If not though, what we can still
    easily do is finish update deltas after, and then ship a *small*
    update that enables deltas.


Oh and all of this blocks on the shadow-utils patch getting into Fedora,
otherwise it's a Fedora Remix. I'm trying to get traction on that, if
I can't get this ~700 line patch reviewed and integrated, I can probably
come up with a hackaround where I temporarily override 
/usr/sbin/{user,group}add
during an RPM transaction.