Hey --
An update on progress with the ostree/atomic work:
lmacken has written up a Fedmsg-triggered composer that runs ostree composes when repos are updated: https://github.com/fedora-infra/fedmsg-atomic-composer. As of our conversation earlier today, it's almost ready for testing in stg. We're thinking that we'll use compose01.stg for this purpose temporarily, since nothing's running on it at the moment. We'll stand up MM1 there and see if we can get it to play with the composer. The idea lmacken suggested is to inject the ostree summary data into the yum metadata, pointing repomd.xml at it (using modifyrepo). IMO this sounds like a solid plan.
That's about it for now. Another update in a few days.
-- oddshocks
On Thu, Oct 23, 2014 at 03:36:03PM -0400, David Gay wrote:
Hey --
An update on progress with the ostree/atomic work:
lmacken has written up a Fedmsg-triggered composer that runs ostree composes when repos are updated: https://github.com/fedora-infra/fedmsg-atomic-composer. As of our conversation earlier today, it's almost ready for testing in stg. We're thinking that we'll use compose01.stg for this purpose temporarily, since nothing's running on it at the moment. We'll stand up MM1 there and see if we can get it to play with the composer. The idea lmacken suggested is to inject the ostree summary data into the yum metadata, pointing repomd.xml at it (using modifyrepo). IMO this sounds like a solid plan.
The current metalink support in ostree expects a binary GVariant ostree summary file directly, and not a yum repomd.xml. https://bug729585.bugzilla-attachments.gnome.org/attachment.cgi?id=283981
I wrote code today that injects the summary into the repodata via modifyrepo, like you mentioned. However, this approach will require rpm-ostree to use librepo to parse the repomd.xml (as root).
If we want to avoid this and get the current MirrorManager1 to support releases with non-xml metalink pointers, then we'd need to extract a timestamp from the ostree summary file instead of the repomd.xml:
https://git.fedorahosted.org/cgit/mirrormanager/tree/server/update-master-di...
This could be done by looking at the filesystem timestamp, or Colin said he would probably add a timestamp field to the summary file that we could pull from.
luke
Thanks again for hacking on this!
On Thu, Oct 23, 2014, at 06:38 PM, Luke Macken wrote:
This could be done by looking at the filesystem timestamp, or Colin said he would probably add a timestamp field to the summary file that we could pull from.
Let's go with filesystem timestamp for now, but I filed a bug for the latter.
On 10/23/2014 03:36 PM, David Gay wrote:
That's about it for now. Another update in a few days.
Thanks much for the update!
Best,
jzb