Miroslav Suchý

COPR and integration with Koji

In my previous post I explained what is (should be) COPR.

Now lets dig into option of merging COPR with Koji code.

The benefit is obvious: We can share the code and resources. Koji have currently one full time developer and aprox. 3 occasional contributors. If I make Koji as backend for COPR I will dedicate more or less half of my time to Koji and Koji will benefit from that.

On the other hand we will have to do some modification to Koji for COPR. I discussed it with Mike McLean (the current Koji developer) and here is the list:

1. uniqueness constraints (currently nevra must be unique in whole koji, we need to be uniq just in one project/koji tag) = 3 weeks
   • Scope: Modify koji to allow multiple builds of the same NVR (and multiple rpms of the same NVRA) to coexist in the system. This will be accomplished by adding namespaces.
   • lift database constraints (constraint includes namespace value)
   • modify filesystem storage to use the unique build id rather than the no-longer-unique NVR (but preserving compatibility for the default namepace)
   • alter a number of calls and commands to be namespace aware
   • add hub calls for manipulating build namespace
   • add policy tests so that admins can make rules base on namespaces
   • optional: scratch builds become null-namespace builds
2. integration with copr = 3 months
   • mostly copr-fe integration
   • plus some additional koji task handlers for the mashing
   • Scope:
     • for every copr project, copr-fe need to create koji tags (and/or namespace from 1)
     • users should be able to modify comps for yum repo (copr-fe may offer some default comps which will include all packages by default)
     • After each successful build we need to trigger mashing (probably new koji/kojira task handler)
     • allow to specify for which architectures (specified per project) you want to build and pass it to koji
3. use VM instead of chroots = 3 months
   • via integration with copr-backend (copr-be)
   • or alternately just generate vm environments in kojid - going with copr-be for now
   • Scope:
     • adapt copr-be to as an alternate build daemon for koji
     • copr-be talks to koji hub instead of copr-fe
     • record data about build environment in koji
       • track as a different type of buildroot (new field in buildroot table)
       • deal with multiple levels of buildroot installations (mockchain)
4. document it = 2 weeks

So the estimation are 7 moths and 1 week. But we can start COPR service with current simple backend service within few week and add Koji as backend later.

What are the benefits and disadvantages of using current COPR code + Koji as backend.

Pros:

• we will spend time on tools which we use on Fedora (koji, mockchain)
• we (or rel-engs) can use the scripts which our rel-engs already have (mash, comps).
• the build process will be exactly the same as in current Koji (but not command, I just mean that we will use mock etc.)

Cons:

• lack of some features we would like (builders restriction, monitoring of builds, etc. see next blogpost about OBS features)
• simple UI
• lack of collaboration support - teams/SIGs working on their set of packages

Note: Even if we go with Koji as backend, it will not means that you can use koji cli command with COPR. Or fedpkg. It will have different cli tool, because the use case and the interface will be different.

In my next post I will talk about benefits and disadvantages of OBS.