|
|
| (24 intermediate revisions by 8 users not shown) |
| Line 1: |
Line 1: |
| {{DISPLAYTITLE:Modularization/Developer Notes}} | | {{admon/important|This page is deprecated| All Fedora Modularity Documentation has moved to the new [https://docs.pagure.org/modularity/ Fedora Modularity Documentation website] with source hosted along side the code in the [https://pagure.io/modularity Fedora Modularity website git repository]}} |
| <div style="float: right;" class="toclimit-2">__TOC__</div>
| |
| | |
| == 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 <code>fed-mod.org</code> domain name no longer works, the IPv4 address is <code>209.132.178.225</code>. We use a shared user account named <code>fedora</code>. If you need access, contact any of the current engineers and provide them with your public SSH key.
| |
| | |
| ==== Automatic COPR rebuilds ====
| |
| | |
| We run automatic [https://copr.fedorainfracloud.org/groups/g/modularity/coprs/ COPR rebuilds] of certain modularity projects (fm, modulemd and modulemd-resolver) with a cron job every 15 minutes. Edit <code>~fedora/rebuild_packages.sh</code> to add yours.
| |
| | |
| ==== Automatic documentation rebuilds ====
| |
| | |
| We also run automatic [http://readthedocs.org/ 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 <code>^/fm/(.+)</code> 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 [http://www.fed-mod.org/taiga-report/ 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 <code>~fedora/fm-trello-taiga-sync</code>, <code>~fedora/sprint_tools</code> and the various related cron jobs.
| |
| | |
| ==== Webhosting in general ====
| |
| | |
| The host is running a generic httpd webserver. The configuration is kept in <code>/etc/httpd/conf.d/fm.conf</code> and we use the default web root for our stuff, <code>/var/www/html</code>. For example, the experimental [http://fed-mod.org/dev/modules/ 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 <code>modules</code> and <code>rpms</code>.
| |
| | |
| ===== dist-git =====
| |
| | |
| For development and testing purposes we use the [http://pkgs.stg.fedoraproject.org/cgit staging dist-git instance] which supports the abovementioned namespaces. The recommended way to interact with dist-git is using the <code>fedpkg</code> tool and configuring it to interact with this instance. To do that, edit <code>/etc/rpkg/fedpkg.conf</code> and change all occurences of the default <code>pkgs.fedoraproject.org</code> to <code>pkgs.stg.fedoraproject.org</code>.
| |
| | |
| ===== pkgdb =====
| |
| | |
| A [https://admin.stg.fedoraproject.org/pkgdb/ 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.
| |
| | |
| ==== The message bus ====
| |
| | |
| We expect to use [http://www.fedmsg.com/en/latest/ fedmsg] extensively for inter-component communication in all stages of module build, testing and distribution.
| |
| | |
| However, since we don't do any of those things yet, there's not much to say about this. Read the upstream documentation to see what Fedora Messaging is about.
| |
| | |
| ==== The module builder ====
| |
| | |
| ===== orchestrator =====
| |
| | |
| ===== koji =====
| |
| | |
| ===== pungi =====
| |
| | |
| ==== The module knower ====
| |
| | |
| ===== PDC =====
| |
| | |
| ===== pdc-updater =====
| |
| | |
| ==== The compose magic ====
| |
| | |
| ===== CaaS =====
| |
| | |
| ===== Pixie dust =====
| |
| | |
| ==== The update system and distribution ====
| |
| | |
| ==== Miscellanous ====
| |
| | |
| ===== pagure.io =====
| |
| | |
| ===== COPR =====
| |
| | |
| ===== Jenkins =====
| |
| | |
| [[Category:Modularization]]
| |
