2:20 p.m.
-----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(a)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-----