(Initial plan) |
mNo edit summary |
||
| Line 3: | Line 3: | ||
Point of contact: Aurelien Bompard | 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. | 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. | ||
| Line 9: | Line 9: | ||
This is also why the migration to fedora-messaging needs to happen before the Gating Rawhide initiative goes to production (development can start, though). | 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: | About 30+ apps require changes. The most critical ones are: | ||
| Line 26: | Line 26: | ||
The other applications will be migrated at a slower pace throughout FY20. | The other applications will be migrated at a slower pace throughout FY20. | ||
=== When? === | |||
* Critical applications: by 2019-06-01 | * Critical applications: by 2019-06-01 | ||
* Other applications: 2020-03-31 | * 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). | 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). | We will start with the application that are most critical (see above). | ||
| Line 45: | Line 45: | ||
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. | 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: | The migration status can be: | ||
Revision as of 12:51, 26 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:
- bodhi
- koji
- greenwave
- waiverdb
- pagure
- centos infrastructure CI
- 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.
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:
- todo: no step has been taken yet
- date set: a date has been decided for the pair programming session
- in dev: a branch has been made and the code migration is in progress
- PR ready: the code migration is done and under review
- merged: the main branch is migrated
- staging: the new code is deployed to staging and under test
- production: the migrated app is running in production
- Bodhi: PR ready
- koji: todo
- greenwave: todo
- waiverdb: todo
- pagure: todo
- centos infrastructure CI: todo
- anitya & the-new-hotness: merged ?