-
Notifications
You must be signed in to change notification settings - Fork 2
Description
Module metadata is a document describing build options, build order and components for a module (packages built as a "group"). These metadata documents are included in the distribution, but as a compiled document (each arch/module/stream has it's own document with a list of artifacts + the base document).
Instead of processing these documents normally, it is viable to process the "src" variant of these through CentOS Stream. Even though Stream is rolling, the module metadata is published in the respective point release branches.
Example:
https://gitlab.com/redhat/centos-stream/modules/389-ds/-/tree/stream-389-ds-1.4-rhel-8.6.0?ref_type=heads (8.6)
https://gitlab.com/redhat/centos-stream/modules/389-ds/-/tree/stream-389-ds-1.4-rhel-8.9.0?ref_type=heads (8.9)
There is currently an implementation to import and match a point release and clean up the metadata (https://github.com/openela/mothership/blob/main/worker_server/modulemd_import/modulemd_import.go) but it is not connected to an entrypoint, or finalized at all.
Code changes we need:
- Finalize and test the import (there are currently no test cases for modulemd import)
- Decide for an entrypoint, options (automated options preferred):
- Poll repos for changes and import on change (automated)
- Wait for workers to flag a module src as updated then import (automated)
- Watch MQ to determine when to import (automated)
- Add as API endpoint and trigger manually for import (manual)
Infrastructure changes:
- Deploy new code
- Make sure selected option is stable and not disruptive (verify poll is not excessive etc.)