Hi folks,

Note: my first email was sent to @fedoraproject.org so sorry for duplication for some of you. This has been tweaked so the output is actually importable into koji test instance with minor tweaks.

I'm working on module build service change that would make it into a content generator similar to what OSBS is doing.

Quick intro around current state: * MBS orchestrates koji builds, tags, etc * Koji AFAIK knows nothing about mbs itself * after finishing the build - mbs creates a module-specific tag and tags every relevant build into it

This is the second stab and what the mbs CG metadata output might look like: https://paste.fedoraproject.org/paste/GM00iYtq55HXCQyXjbEVZV5M1UNdIGYhyRLivL...

I was actually able to import the above into a test koji instance (after some SQL additions of new types etc).

Notable things: * outputs - missing logs. Do we need them? Each module is basically a collection (repository) of rpms built in koji which each have their own logs. We could probably add orchestration logs later? * tools, components - Not sure there's any set of specific tools worth mentioning. Maybe version of koji client library? * container - MBS makes no use of container so the "type" is none, but we still have to specify the architecture or koji complains on import. * "typeinfo" keys in build and output fields - I am a little confused. When I tried to copy what OSBS is doing in the extra fields koji refused to import the metadata. Current metadata is based on some experimentation and adjustments based on error messages. I think some guidance on the structure of the types and typeinfo(s) would be nice since they don't seem to be up to date with documentation.

And most importantly: the modulemd type output - this would be a modulemd.yaml file that contains the mmd content [1] once downloaded - component metadata list would include all the rpms that are tagged in the final module tag - all architectures, subpackages etc - notably no signatures would ever be mentioned here since they are not fixed at the end of module build unlike container builds

There was an idea to split the modulemd into separate arch-specific pieces, but it didn't bring anything useful to the table so was scratched.

Would the above approach be generally acceptable? Is there any concern about adding components for file that is just metadata? Anything else I might have missed?

Thanks,

[1] can be seen as "modulemd" in https://mbs.fedoraproject.org/module-build-service/1/module-builds/199?verbo... [2] WIP PR for the MBS change is here: https://pagure.io/fm-orchestrator/pull-request/522#