I am currently doing some manual testing of my code, and it proved to be vital. It helped me figure out a lot of bugs. One of seemed weird to me in the beginning:
The get here(https://github.com/sayanchowdhury/darkserver/blob/config/darkimporter/libimporter.py#L310) returned an error

Method Not Allowed
This is an XML-RPC server. Only POST requests are accepted.

The project required a heavy amount of download, so my mentor gave me a dev instance to test out my code, all seemed to be fine, with the code properly working on local machine. But on the dev instance a major bug surfaced, all the architecture with referring to the same key. So, currently i started working on implementing different darkproducer-ids for different darkproducers.Also, I need to get started with a long-term bug, my mentor pointed me in the shutdown functionality of darkserver.

It’s been two weeks since i last posted my report on Darkserver. I could not post week two update as I had been down with bad health(seasonal changes + Loo). With the week coming to an end and /me recovering from fever, i badly hurt my right wrist and that was end of it. I somehow manage to move myself to a new city, Bengaluru. The week passed as a trauma for me 😥

After recovering, i was back to coding/resolving issue in darkserver. Starting from the mid of week three, I started working on implementing the support for secondary architecture. Darkserver now supports secondary architecture(arm, ppc).

Defining the current structure of Darkserver:

darkproducer

$ darkproducer --start=BUILD_ID --config=CONFIG
Options:
-s BUILD_ID, --start=BUILD_ID Specifies the build id
-c CONFIG, --config=CONFIG Specifies the Config file

The config files points to either of the configuration files for Koji, ARM, PowerPC. The files being darkserverurl-koji.conf, darkserverurl-arm.conf, darkserverurl-ppc.conf placed under configs/. The default being for koji.

A “url” key was added to retask Queue to maintain the relation between the build_id and the architecture.
The command line arguments in Darkserver are currently now parsed by optparse python module.
So, a pid is added to darkbuildqueue and darkjobworker, so the command line arguments now is:

darkbuildqueue:

$ darkbuildqueue --start --pid=1
Options:
-s, --start start the buildqueue
-p PID, --pid=PID specify the pid for build queue

darkjobworker:

$ darkjobworkder --start --pid=1 // To start job worker 1
$ darkjobworkder --start --pid=2 // To start job worker 2
$ darkjobworkder --stop --pid=1 // To stop job worker 1
Options:
-s, --start start the buildqueue
-e, --stop stop the buildqueue
-p PID, --pid=PID specify the pid

The “Google Summer of Code” code period began on June 17 and it’s already one week into it. Prior to the beginning of the coding period, I went into the depths of the darkserver codebase. In the current version of Darkserver, the link present in the libimporter are hardlinks and it is pretty well visible here https://github.com/kushaldas/darkserver/blob/master/darkimporter/libimporter.py#L328

So, I removed the urls and the values from the libimporter and made it configurable via config files. The config files are currently present in the configs/ directory. This will eventually help to allow us to add different job queues for different secondary architectures.

According to the Darkserver wiki, the steps for starting the darkproducer is:

$ darkproducer start KOJI_BUILD_ID

Now, after removing the hardlinks and making it accesible through config files, the steps to start the darkproducer is:

$ darkproducer start KOJI_BUILD_ID --config=/path/to/config/file

The configuration file for koji should be in form of:

[darkserver]
url = 'http://koji.fedoraproject.org/kojihub/'

In case of violation, the –config option defaults to /etc/darkserver/darkserverurl-koji.conf

Next, I would be aiming for implementing the support for the secondary architectures, arm, ppc and add support to maintain different job queues for the different secondary architectures.