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/GM00iYtq55HXCQyXjbEVZV5M1UNdIGYhyRL...
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?ve...
[2] WIP PR for the MBS change is here:
https://pagure.io/fm-orchestrator/pull-request/522#
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Business System Analyst, PnT DevOps - Brno
PGP: F434 2286 27DC 7D9B 2B64 0866 BCBD 752E 7B08 7241
Red Hat Inc.
http://www.redhat.com