composing/shipping OSTree trees

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Colin,

I have had this on my todo to respond to. just been very hectic.

On Thu, 15 May 2014 15:37:51 +0000
Colin Walters <walters at verbum.org> wrote:

> 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.
what do you mean by not mirroring to all the mirrors? we dont get to
pick and choose what goes where.mirrors choose what they want to
mirror. I have started a conversation with them but have had no
response. i suspect we may only hear from them when they start having
issues.

> 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.

without knowing the details of the parts you talk about here I can not
give you any feedback on any of it.

>     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.

I do not know how the update process works, and have zero clue about
how we can tell the updates process to use mirrormanager to find the
mirrors to pull from.

Basically we just dont have anywhere near enough information to proceed.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJTjM6FAAoJEH7ltONmPFDRvjgQAMFnfOgEw9wO4i9rFQkHIxuo
7AX3kWh+rzjyy92Pf654pnYwXPY2iR+H9np4nWdf0ZKJsoq9QL4o33N3kdJjpUEi
V+L5J/XRVIWU72o8WP31nvLUXtOOANqo9rT/MYkIlXdHhMNwsHJIW42j5nSHpi+r
MxHJH4yUvzGewW4GIVNmnJ3BGCtNDQnU3bZ7b1Al6DeWJvQa/W5rbJNJz0GK7Uq+
o0VYsBa0TrFqUZqLE6nT5uI0uuvWbRD+7gx1H6lJxnWKazIWZdEx3c6vmCykK0V+
99ghDuEPpgmDzTkmNvVRpotKDThALv77i4MRUieFTVSdcn4KswZJmSTap0qlLqVK
5F72AtmVZ8IQsklWjGA0KrsxVfmOSj+nEOdfvEIlQofDRdw0TaH7m+hqtq3xYdzN
b6CI9z//XRhUb4O/054sXJ9CvWIPngJUNrKCrgpbuDW7dqhtsApYDnWJgJQpf3QC
/8H4IDuk/KlbFDbvXLCdvtKI0BQBwomFvlUtklwBhm98u2jf+UpeYSw3PW8PfL8e
4e9/tC9Pp1WQxhosB9pXeGWvIBl1G4YImXvrx4uYL4HGjx1hDco1GRzXm073MBD/
xpNybF0ZFWtJ5zy1Z1mEAy1PFzW/Imqj9gthSP9GyIRFQ9tQgdgKkt7BlQ6ERRJz
gSOu9PRr//35HyTaQcNP
=VxjM
-----END PGP SIGNATURE-----