Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: add container metadata #91

Open
ktdreyer opened this issue May 18, 2017 · 2 comments
Open

RFE: add container metadata #91

ktdreyer opened this issue May 18, 2017 · 2 comments

Comments

@ktdreyer
Copy link
Member

It would be great if Pungi wrote official productmd metadata about the container(s) it builds in Koji.

@ktdreyer
Copy link
Member Author

ktdreyer commented Jun 1, 2017

Pungi currently writes to compose/metadata/osbs.json, so I think we'd want a new productmd.containers.Containers class or something here?

@lubomir
Copy link
Contributor

lubomir commented Jun 2, 2017

The first step should probably be documenting what data is actually in the file and what should be there.

If I recall correctly, it's currently basically a mapping Variantarch → list of images. In order to properly integrate with the rest of productmd files, it should probably be moved under payload.osbs key and gain information about compose and header with versioning information.

Is there some information missing?

The current keys that I think are essential:

  • checksum
  • creation_time
  • name
  • release
  • size
  • version
  • image – a dict that currently only contains arch key, maybe it should by flattened to just an arch

Keys that should be removed:

  • compose_id – there should be a compose block with all the info anyway

Up for discussion:

  • filename – is this useful? The file is not available anywhere in the compose dir anyway.
  • koji_task – this makes no sense without information about which Koji instance this refers to (which is not available in this metadata), and it should be possible to get this based on NVR of the image

And then there is the docker key. It contains a ton of info (some with dubious usefulness), and the data comes directly from Koji, so the exact contents can differ.

Another question is how to deal with scratch builds. Currently the data about them is significantly different to production builds (https://pagure.io/pungi/issue/485).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants