Miroslav Suchý

COPR implemented using OBS

In my previous post I explained what is (should be) COPR and what are benefits and disadvantages of integrating with Koji.

Now I focus on Open Build Service (OBS) as alternative to existing COPR code.

WebUI is written in Ruby/Rails and store nothing in DB (but session id). It is completely isolated and communicate with API component using REST. WebUI supports themes and can be quite easily rebranded.

API component is part which stores data. And provides them to Backend and WebUI.

Backend do the actual building. Well there are several components, which try to follow KISS principle. Packages (both sources and results) are handled very securely. Builder retrieve sources and start up KVM guest and do build there. This guest is then disposed after build.

Upstream is very responsive and is willing to merge pull request even if they are not related to SuSe (as far as it can be enabled/disabled by configuration directive).

OBS have several advances:

• it is mature code (it is here since 2006)
• it have 6 core developers from SuSe and quite large existing community (not just from SuSe)
• it have lots of features (see below)
• we can show we do not suffer from NiH syndrome and we can cooperate with different distributions

On the other hand it have some disadvantages:

• it does not use mock, but script called build, which then directly call rpmbuild
• dependency resolving is done on OBS server side using satsolver, so it is potential that binary packages can be different from what produce Koji. However once we start using dnf (which use satsolver), the resolution should be the same.
• it is completely different workflow then we all know from Koji
• we split our work between two different tools: Koji for Standard Fedora and OBS for COPR.
• we would need add to OBS file based dependencies support

OBS have features which even Koji do not have:

• support for teams, and ACL.
• generate repository (current COPR do that, but Koji not).
• can constraint builder (e.g only build on host with at least X RAM ...)
• monitoring of yours packages - example
• better documented
• preinstall images
• Connection of instances - you can (re)use repositories on different instance of OBS.
• Multi architecture support - using cross compile http://openbuildservice.org/files/talks/OBS-Cross-Build.pdf
• Builds for other distributions - For one package you can define more distributions - RHEL, EPEL, Mandriva, Suse or even Debian etc.
• Collaboration on packages - you can fork package, make changes, test your builds and then submit changes back to original author
• Different package formats - e.g. Debian format can be interested for layered applications.
• Can fetch sources directly from GIT/SVN/URL.
• Controls via Web Interface - you can easily create new project, set up ACL...
• can create virtual images (albeit just Kiwi).
• build package in VM, which is safer then Koji (just chroot in Koji). And that VM is without network, which is safer then current COPR which allows network connections.
• Better monitoring of builders

Right now we have all build dependency of OBS in Fedora. We already have client cli tool of OBS (called osc) in Fedora as well. I would probably need little more than month to package OBS for Fedora. 4 months to learn OBS internals and some problems to be able to build Fedora package (e.g. they may have other differences in multilib). One month to setup instance. So to sum it up we can have functional OBS in about 6 months.

The question is: which way we want to go?