Abstract
The purpose of this document is to describe systems and services used for generic Modularization development, research and possibly future infrastructure deployments, and is intended as a reference guide for the involved engineers and the so-called doers-of-things.
If you're new to Modularization, start with the following instead:
Systems
We use a number a systems for Modularization work. Some of those are dedicated installations for our cause, some are generic and shared with other Fedora initiatives. This section focuses on the former.
fed-mod.org
The main and currently the only dedicated system we have.
This is an OpenStack instance running Fedora 21. In case the fed-mod.org
domain name no longer works, the IPv4 address is 209.132.178.225
. We use a shared user account named fedora
. If you need access, contact any of the current engineers and provide them with your public SSH key.
Automatic COPR rebuilds
We run automatic COPR rebuilds of certain modularity projects (fm, modulemd and modulemd-resolver) with a cron job every 15 minutes. Edit ~fedora/rebuild_packages.sh
to add yours.
Automatic documentation rebuilds
We also run automatic readthedocs.org documentation builds every 15 minutes for fm and modulemd with simple cron jobs.
Metadata service
The metadata-service is deployed on this system and handles all ^/fm/(.+)
HTTP requests. This API isn't really defined yet. Browse the project's sources to see how it works.
Status reports and agile tools
Our Taiga status reports are also hosted on this sytem and regenerated every 15 minutes, again, with a cron job.
Other agile tools such as the Modularity Bot or sprint-tools for Trello/Taiga synchronization are also hosted here. See ~fedora/fm-trello-taiga-sync
, ~fedora/sprint_tools
and the various related cron jobs.
Webhosting in general
The host is running a generic httpd webserver. The configuration is kept in /etc/httpd/conf.d/fm.conf
and we use the default web root for our stuff, /var/www/html
. For example, the experimental modules repository is hosted there.
Feel free to use this for whatever you need. However, keep in mind the available disk space on this machine is fairly limited.
Services
The high-level purpose of the majority of the services listed below is described in the Modularization/Infra document.
The input
Module input data consists of two main parts — the module definition file in the modulemd format and the components, such as RPMs (coincidentally the only format we currently support but expect that to change at some point in the future). In Fedora, both the modulemd files and the components' SPEC files are stored in dist-git and the associated ACLs are stored in pkgdb (Package Database).
We use namespaces to distinguish between modules and RPMs in those two systems, aptly named modules
and rpms
.
dist-git
For development and testing purposes we use the staging dist-git instance which supports the abovementioned namespaces. The recommended way to interact with dist-git is using the fedpkg
tool and configuring it to interact with this instance. To do that, edit /etc/rpkg/fedpkg.conf
and change all occurences of the default pkgs.fedoraproject.org
to pkgs.stg.fedoraproject.org
.
pkgdb
A staging pkgdb instance is also available, storing the modules' ACL entries.
Contact people with the admin ACL privileges for the given module for commit access. Contact User:Ralph if you need a new module pkgdb entry & dist-git repository.