From Fedora Project Wiki

(Details about OpenQA & Pagure, warn about consumers)
(Investigate fedmsg.config usage)
Line 89: Line 89:
  
 
Greenwave has 2 consumers (ResultsDB and WaiverDB) and produces one message topic.
 
Greenwave has 2 consumers (ResultsDB and WaiverDB) and produces one message topic.
 +
The fedmsg config is used to store the consumers' configuration.
 +
There are only 2 calls to ''fedmsg.publish''.
  
 
==== WaiverDB ====
 
==== WaiverDB ====
Line 94: Line 96:
 
Source code: https://pagure.io/waiverdb
 
Source code: https://pagure.io/waiverdb
  
WaiverDB only produces one message topic.
+
WaiverDB only produces one message topic. It does not use the fedmsg configuration to store its own configuration. There's only one call to ''fedmsg.publish''.
  
 
==== ResultsDB ====
 
==== ResultsDB ====
Line 100: Line 102:
 
Source code: https://pagure.io/taskotron/resultsdb
 
Source code: https://pagure.io/taskotron/resultsdb
  
ResultsDB only produces one message topic.
+
ResultsDB only produces one message topic. There are only 2 calls to ''fedmsg.publish''.
  
 
==== Pagure ====
 
==== Pagure ====
Line 106: Line 108:
 
Source code: https://pagure.io/pagure/
 
Source code: https://pagure.io/pagure/
  
Pagure only sends messages.
+
Pagure only produces messages, calls to ''fedmsg.publish'' are centralized, and ''fedmsg.config'' is not used to store app configuration.
  
 
==== CentOS Infrastructure CI ====
 
==== CentOS Infrastructure CI ====
Line 120: Line 122:
 
* org.fedoraproject.*.bodhi.update.request.testing
 
* org.fedoraproject.*.bodhi.update.request.testing
 
* org.fedoraproject.*.bodhi.update.edit
 
* org.fedoraproject.*.bodhi.update.edit
 +
 +
The fedmsg configuration is only used to decide which consumer to enable.
  
 
==== Anitya ====
 
==== Anitya ====

Revision as of 06:51, 29 January 2019

This is a shorthand list of items we are needing to cover for migrating from fedmsg to fedora-messaging in Fedora Infrastructure for the Fiscal Year 2020.

Point of contact: Aurelien Bompard

Why?

Fedmsg has a number of issues but the main one is that it is unreliable. Since critical elements of our CI pipeline (and general infrastructure) are depending on it, it is important to migrate to fedora-messaging to solve that issue.

This is also why the migration to fedora-messaging needs to happen before the Gating Rawhide initiative goes to production (development can start, though).

What?

About 30+ apps require changes. The most critical ones are:

  1. bodhi
  2. koji
  3. greenwave
  4. waiverdb
  5. pagure
  6. centos infrastructure CI
  7. openqa
  8. anitya & the-new-hotness

Migrating to fedora-messaging will also allow us to define schemas for our data, use versions on the topic to avoid breakage in the message consumers, and rethink the topic to make them more useful with the routing capabilities we have. However, these tasks are out of scope for this initiative, for time/resources reasons.

The other applications will be migrated at a slower pace throughout FY20.

When?

  • Critical applications: by 2019-06-01
  • Other applications: 2020-03-31

Who?

The people involved will be abompard and the owner of each app (be it for writing the migration or for reviewing and testing it).

How?

We will start with the application that are most critical (see above).

The changes from fedmsg to fedora-messaging are usually similar in each application, so it can be a great opportunity for pair programming between abompard and the app owners.

It is however more complex to migrate an app that has consumers, because a new systemd service file must be written (and maybe a new script). In fedmsg only a class had to be defined and the system's fedmsg-hub daemon would pick it up. It's no longer how consumers work in fedora-messaging.

The staging and production networks are ready for fedora-messaging, so the migration and testing can start immediately.

Since this is a significant change from a deployment point of view, app owners may decide to change their major version number, but this decision is left to them.

Status

The migration status can be:

  1. todo: no step has been taken yet
  2. date set: a date has been decided for the pair programming session
  3. in dev: a branch has been made and the code migration is in progress
  4. PR ready: the code migration is done and under review
  5. merged: the main branch is migrated
  6. staging: the new code is deployed to staging and under test
  7. production: the migrated app is running in production
  • Bodhi: PR ready
  • Koji: todo
  • Greenwave: todo
  • WaiverDB: todo
  • Resultsdb todo
  • Pagure: todo
  • Centos Infrastructure CI: todo
  • OpenQA: todo
  • Anitya: PR ready
  • The-New-Hotness: in dev

Details per-app

Bodhi

The producing side on the server is already migrated to fedora-messaging. Some PRs are left to merge: consumers , message schemas.

The migration to Fedora Messaging should be available in Bodhi 4.0

Koji

Koji sends fedmsgs via a plugin, this plugin should be migrated. I did not find any upstream source control for the koji plugin, unless I'm mistaken it only lives in the Infra Ansible repository. Ideally, we would create an upstream project for that with its proper git, tracker, releases, tags, etc.

Greenwave

Source code: https://pagure.io/greenwave

Greenwave has 2 consumers (ResultsDB and WaiverDB) and produces one message topic. The fedmsg config is used to store the consumers' configuration. There are only 2 calls to fedmsg.publish.

WaiverDB

Source code: https://pagure.io/waiverdb

WaiverDB only produces one message topic. It does not use the fedmsg configuration to store its own configuration. There's only one call to fedmsg.publish.

ResultsDB

Source code: https://pagure.io/taskotron/resultsdb

ResultsDB only produces one message topic. There are only 2 calls to fedmsg.publish.

Pagure

Source code: https://pagure.io/pagure/

Pagure only produces messages, calls to fedmsg.publish are centralized, and fedmsg.config is not used to store app configuration.

CentOS Infrastructure CI

OpenQA

Source code: https://pagure.io/fedora-qa/fedora_openqa

Consumers for the folowing topics:

  • org.fedoraproject.*.openqa.job.done
  • org.fedoraproject.*.pungi.compose.status.change
  • org.fedoraproject.*.bodhi.update.request.testing
  • org.fedoraproject.*.bodhi.update.edit

The fedmsg configuration is only used to decide which consumer to enable.

Anitya

Owner: Michal Konečný

Source code: https://github.com/release-monitoring/anitya

In current state Anitya is consuming and publishing various topics. Publishing only in future (See bellow).

PR with first draft of publishing migration to fedora messaging https://github.com/release-monitoring/anitya/pull/570. This PR will be merged shortly.

Anitya consumes libraries.io topics. However this will be removed and the SSE consumer will be part of Anitya instead of standalone application (It is the only application that is actually listening to libraries.io publisher). After this change Anitya will not consume any topics.

The-New-Hotness

Owner: Michal Konečný

Source code: https://github.com/fedora-infra/the-new-hotness

The-new-hotness is consuming and publishing few topics.