koji

April 25, 2008

With some help from Simon we now have the koji service mostly up and running at http://koji.inf.ed.ac.uk/koji/. It doesn’t actually do anything useful yet but there is some hope that it can now be battered into working the way we need. The code makes lots of assumptions that the world works in a way that mirrors the redhat network. For instance, they assume that the kerberos realm can be found from the last two parts of the FQDN for a machine. That works fine for foo.redhat.com but rather less well for telford.inf.ed.ac.uk, thankfully it is all written in python and is fairly easy to modify.

After further investigation I think the koji service generates mock configurations on the fly and it also appears that it doesn’t use external yum repositories. It appears that all the packages need to be imported for each distribution. I guess that koji has been designed around the idea of building an entire distribution. I’m not sure how this fits with us wanting to build a smaller set of packages targetted at one of “world“, “uoe” or “inf” for different platforms (e.g. fc6 and sl5). I need to get the service fully functional and then start experimenting.

One other thing I’ve done is that I’ve reworked the headers into two separate parts:

  • dice/options/koji-hub.h
  • dice/options/koji-builder.h

There is only ever one hub but it is possible to use any number of builder machines, for now both parts are on telford.


koji

April 18, 2008

I’ve now started work on getting the koji service running on telford. There is a huge amount of information to get my head around so that I can actually understand the architecture and how it is all intended to slot together. The main references are a couple of wiki pages:

In some parts they go into great detail but in other places there is a complete lack of information so this is going to take a while… I’ve put together a few headers to get things working:

  • lcfg/options/git.h – For some reason koji needs the whole suite of git tools so I thought it best to put these into a separate header to aid reuse.
  • lcfg/options/mock.h – This adds the necessary mock packages and the mock LCFG component. It doesn’t set up any chroots by default, you need to do that yourself.
  • dice/options/koji.h – This is a start at configuring the koji system. I am currently working on the “put it all on one machine” principle, if necessary the parts can be split out later to cope with having a set of build servers. Currently this gets a PostgreSQL DB server running and apache setup with mod_python.