#22 consider merging into Koji (or a Koji plugin)
Opened 2 months ago by ktdreyer. Modified 2 months ago

My team and I have experienced integration issues when applying changes to Ursa Major's configuration.

We have several tags and several product versions going on, and the velocity at which we are managing these product versions is increasing. We're seeking a straightforward way to add and remove modules from our tags without manual commands.

Unfortunately we run into some problems, like our ursa-major CI fails for unclear reasons, or there are access problems, etc. It seems to me that many of the conflicts occur because there are (at least) two sources of truth: 1) the Koji hub database for tag inheritance, and 2) the ursa-major-config JSON file, and it is really difficult to keep these two in sync.

We could improve these issues if we built first-class support for modules into Koji (or at least into a Koji Hub plugin).

If modules were first-class objects within Koji, then the hub could immediately update inheritance every time a new module arrived. Koji is great at doing this for RPMs with normal build inheritance. I bet if we talked with @mikem and @tkopecek about this, we could brainstorm some good ideas.


@ktdreyer, there's a proposal going around that would do away with ursa-major completely.

Thanks @lucarval . I read that document and it was not apparent to me that it meant ursa-major would completely go away. I guess this is saying that MBS would set various external-repos on tags?

@ktdreyer, I believe so, but @psabata is the best person to answer that.

I also thought, that getting rid of Ursa is the current plan. But if not, making ursa a koji plugin could be way to go. In such case, ursa will have access to db and API in same place as koji hub. It should solve mentioned problems (I've not ever got through the ursa sources, so not sure how much effort it could take).

Login to comment on this ticket.

Metadata