Modularity/Development/Developer Notes

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:

• Modularization
• Modularization/Getting_involved
• Modularization/Infra

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.