MBBox is a way to deploy everything you need to build modules in Fedora/CentOS ecosystems. It contains Koji (koji-hub, koji-builder, kojira) and MBS (mbs-frontend and mbs-backend). This should be enough to start building your own modules. It is now one of the initiatives being worked on by the CPE team.
Why is the CPE team working on this?
Originally there was a Python script written by our former colleague Patrick Uiterwijk which did the deployment of the MBBox. The initiative was submitted by the CentOS Stream team because they were the main users of the original MBBox script. The requirements in the initiatives were following:
- Create OpenShift templates
- Allow usage of Certification Authority already present in infrastructure
- Use Fedora messaging instead of fedmsg
- Allow usage of messaging bus already present in infrastructure
- Automatic build of the container images
- Automate upgrade procedure of MBBox components
- Include the MBBox templates in OpenShift catalogue
After initial analysis of the requirements demanded by the CentOS Stream team, we decided to split this initiative in two phases and changed the requirements slightly. We are currently working on phase one of this initiative, which will be finished by the end of June. The final requirements for phase 1 are:
- Create Kubernetes operator (templates are obsolete in OpenShift 4 and to target a wider audience, we decided to go with Kubernetes operator, which works on both Kubernetes and OpenShift 4)
- Allow usage of Certification Authority already present in infrastructure (original python script deployed its own)
- Use fedora-messaging instead of fedmsg (with exception of MBS, which doesn’t support fedora-messaging yet, we will try to help them if we have any spare time)
- Allow usage of messaging bus already present in infrastructure (original script deployed its own fedmsg server)
- Include the MBBox operator in Kubernetes catalogue
As you can see this project will help the CentOS Stream team and allow anyone running Kubernetes cluster to benefit from this work.
The team started working on this initiative at the beginning of the second quarter (April). The team consisted of 3 people (asaleh – Adam Saleh, lrossett – Leonardo Rossetti, and mkonecny – Michal Konečný). This was our first initiative when we tried agile methodology, more specifically Scrum. We decided to use 2 weeks sprints, because we already spent some time on some of the tickets and the work took plenty of time. First we created a devel environment in Vagrant, because the team was already familiar with it. But there are also instructions in docs on how to run our own using minikube.
From a technology standpoint we decided to code Kubernetes operator in Ansible. This choice was done because the team was already familiar with Ansible and most of the MBBox components are written in Python, so it’s easier to integrate with them using Ansible.
Team started to work on koji-hub and koji-builder. Except for lrossett Kubernetes operators were a new technology for the team, so we struggled with it at the beginning. But in the mid of May we had a koji-hub running together with a koji-builder. I’m really glad we have lrossett in our team, because his knowledge was invaluable.
At the same time I (mkonecny) worked together with lrossett on koji components, asaleh worked on establishing the CI for the project. Originally we wanted to go with CentOS CI, but decided to go with Zuul later on, because it was easier for us to set up our own vm machine for testing. Thanks to work by asaleh we can now run CI tests on every PR.
Currently we are in the last sprint. We have deployment done for koji-hub, koji-builder, kojira, mbs-backend and mbs-frontend. We are working on a shared component that will glue everything together and on a staging environment to have publicly accessible instance for testing in OpenShift 4. We also need to document the deployment process, clean the project structure a bit (removing original python script bits) and add the operator to the public kubernetes registry.
After phase one will be done, remaining work will be moved to phase two. From the initial requirements this means automatic update of components and automatic build of new container, when a new version of components is released. The support of fedora messaging for MBS will probably also move to phase two.