pungi

#544 Add OSTree metadata into the compose
Opened by walters. Modified

Open
Close Issue

It looks like we already extract the hash:

        if compose.notifier:
            ref = get_ref_from_treefile(os.path.join(repodir, config['treefile']),
                                        arch, logger=self.pool._logger)
            # 'pungi-make-ostree tree' writes commitid to commitid.log in logdir
            commitid = get_commitid_from_commitid_file(os.path.join(self.logdir, 'commitid.log'),
                                                       logger=self.pool._logger)

but we don't insert it into the metadata. I think we should. It would lay the groundwork for a few things:

  • Ensuring that the media uses that exact commit; once we move to continuous generation, it's possible another ostree commit is generated while a previous image run is starting, and then the image (ISO/cloud) might or might not pick up the new commit
  • Use the OSTree version for image filenames, not the pungi one; see https://pagure.io/atomic-wg/issue/229

Do you have any suggestion what should the metadata look like? Would a new file in compose/metadata/ (something like ostree.json?) directory work? What data would you expect in it? Just the ref and commit id? (Plus information about the compose id, date, type etc.)

There's a related issue #258. I don't think we need to go to productmd immediately, we can do a couple iterations in Pungi to find out the ideal format.

I was thinking of it more in the toplevel compose metadata, like:

 "payload": {
        "compose": {
            "date": "20170306",
            "final": true,
            "id": "Fedora-Atomic-25-20170306.0",
            "label": "RC-20170306.0",
            "respin": 0,
            "type": "production"
            "ostree": { "commit": "98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb1107be4",
"version": "26.2017.8",
"timestamp": "2017-03-04 16:09:46"
"ref": "fedora/26/x86_64/atomic-host"
"repo": "https://kojipkgs.fedoraproject.org/atomic/26/"
}
        },

In my view...the ostree commit is the fundamental root of the compose (assuming the compose doesn't contain non ostree content - that's a whole topic in itself). The RPMs aren't strictly necessary, and the images conceptually could come after.

Put another way...I think one viable model would be to have two types of compose; "ostree" and "ostree-images". They would operate asynchronously - the "ostree-images" compose would capture the latest commit in the last "ostree" compose or so.

I guess a lot of this is predictated on whether or not we end up supporting/making composes that either:
- Also contain traditional RPM + media stack
- Multiple ostree-based systems

Things get a lot simpler if we don't mix them - it's easier to implement things like having the image filenames use the ostree version + a serial number as proposed inthe atomic-wg ticket above.

It may be simplest to have the metadata split out separately to start as you propose though.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/pungi/pungi/issues/544

Please continue any further discussion there.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.