As I stated in the previous post, the next step here was to setup databases. I spent time attempting to have sqlite work in this situation, but ran into issues with buildapi connecting to the sqlite databases. Rather than chase that rabbithole, I doublechecked the configuration in production buildapi and was reminded by the configs that production is running mysql. So I went ahead and did so. This setup required adding the following to the Dockerfile:

RUN apt-get install -y mysql-server

RUN chown mysql.mysql /var/run/mysqld/

RUN mysql_install_db # Installs mysql database schemas

RUN /usr/bin/mysqld_safe &

After this, everything was peachy except for the sql schemas available in the current buildapi repo. Those schemas are for sqlite, so I dumped my own mysql schemas for use here, and loaded them with the following commands:

mysql < status_schema.mysql

mysql < scheduler_schema.mysql

I went ahead and submitted a patch to add the mysql specific schemas to the buildapi repo in Bug 1007994, but for now I added the schemas in with the files in the buildapi-app directory.

I uploaded the current contents of the buildapi-app docker container and it launches with schemas all loaded and running well.

I am still having some issues verifying that selfserve-agent can execute commands from data sent to it over the amqp by buildapi. Further testing is needed to fix this issue. I am currently getting 404 error with my tests, but that might be a peripheral problem rather than selfserve-agent not getting data from the amqp.

Left to do on buildapi-app is to:

• Test that buildapi and selfserve-agent are truly connected and able to exchange over the amqp
• Test the entire buildapi application by running similar procedures that should work in my local setup

Links I found useful for this:

• http://ijonas.com/devops-2/building-a-docker-based-mysql-server/

http://johnzeller.com/blog/2014/05/08/mysql-databases-are-all-setup-in-buildapi-docker-container/