composing/shipping OSTree trees
walters at verbum.org
Thu May 15 15:37:51 UTC 2014
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
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
client systems can use as an online upgrade source *post*
- Should this be a Koji plugin? Or should the treecompose be a
* 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
- 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:
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
during an RPM transaction.
More information about the rel-eng