Infrastructure/infra-docs-fpo
3
0
Fork 0
Code Issues 100 Pull requests 6 Projects Releases Packages Wiki Activity Actions

Remove fedmsg and github2fedmsg from documentation

Browse source 
This commit removes all the documentation related to fedmsg and
github2fedmsg. Removes all the mentions of fedmsg when it makes sense or
change it to Fedora messaging.

I didn't updated
modules/releng_misc_guide/pages/sop_pushing_updates.adoc as this needs
somebody with the knowledge of the process to update it.

Signed-off-by: Michal Konecny <mkonecny@redhat.com>
This commit is contained in:
Michal Konecny 2025-02-03 11:11:06 +01:00 • committed by zlopez
parent 2c72e82f01
commit b2f3b6589a
19 changed files with 18 additions and 1136 deletions
Download patch file Download diff file Expand all files Collapse all files

4
modules/release_guide/pages/contributing.adoc
View file

@ -224,8 +224,8 @@ variety of operating system/cloud combinations.
* https://pagure.io/sigul[sigul] -An automated gpg signing system
* https://github.com/rpm-software-management/mock/wiki[mock] -a tool for
building packages in prestine buildroots
* http://www.fedmsg.com/en/latest/[fedmsg] -Fedora Infrastructure
Message Bus
* https://fedora-messaging.readthedocs.io/en/stable/[Fedora Messaging]
-Fedora Infrastructure Message Bus
* https://github.com/rhinstaller/lorax[lorax] -tool to build install
trees and images
* http://www.openshift.org/[OpenShift] -Open Source Platform as a

30
modules/release_guide/pages/layered_image_build_service.adoc
View file

@ -17,8 +17,6 @@ created from a Dockerfile and builds on top of that base image.
| Future Items to Integrate |
+------------------------------+
| +--------------------------+ |
| |PDC Integration | |
| +--------------------------+ |
| |New Hotness | |
| +--------------------------+ |
| |Other??? | |
@ -62,7 +60,7 @@ created from a Dockerfile and builds on top of that base image.
| | |
[docker images] | |
| | |
| [fedmsg] |
| [fedora messaging] |
+---------------+-----------+ | |
| | | +---------------+
| +----------------------+ | | |
@ -115,7 +113,7 @@ The main aspects of the Layered Image Build System are:
* A docker registry
** docker-distribution
* Taskotron
* fedmsg
* Fedora messaging
* RelEng Automation
The build system is setup such that Fedora Layered Image maintainers
@ -142,9 +140,9 @@ world verifying that all sources of information come from Fedora.
Completed layered image builds are hosted in a candidate docker registry
which is then used to pull the image and perform tests with
https://taskotron.fedoraproject.org/[Taskotron]. The taskotron tests are
triggered by a http://www.fedmsg.com/en/latest/[fedmsg] message that is
emitted from https://fedoraproject.org/wiki/Koji[Koji] once the build is
complete. Once the test is complete, taskotron will send fedmsg which is
triggered by a https://fedora-messaging.readthedocs.io/en/stable/[Fedora messaging]
message that is emitted from https://fedoraproject.org/wiki/Koji[Koji] once the build is
complete. Once the test is complete, taskotron will send fedora message which is
then caught by the [.title-ref]#RelEng Automation# Engine that will run
the Automatic Release tasks in order to push the layered image into a
stable docker registry in the production space for end users to consume.
@ -230,13 +228,13 @@ be held in DistGit and maintained by the Layered Image maintainers.
https://pagure.io/releng-automation[RelEng Automation] is an ongoing
effort to automate as much of the RelEng process as possible by using
http://ansible.com/[Ansible] and being driven by
http://www.fedmsg.com/en/latest/[fedmsg] via
https://fedora-messaging.readthedocs.io/en/stable/[Fedora messaging] via
https://github.com/maxamillion/loopabull[Loopabull] to execute Ansible
Playbooks based on fedmsg events.
Playbooks based on Fedora messaging events.
==== Robosignatory
https://pagure.io/robosignatory[Robosignatory] is a fedmsg consumer that
https://pagure.io/robosignatory[Robosignatory] is a Fedora messaging consumer that
automatically signs artifacts and will be used to automatically sign
docker layered images for verification by client tools as well as end
users.
@ -247,17 +245,9 @@ In the future various other components of the
https://fedoraproject.org/wiki/Infrastructure[Fedora Infrastructure]
will likely be incorporated.
===== PDC
https://pdc.fedoraproject.org/[PDC] is Fedora's implementation of
https://github.com/product-definition-center/product-definition-center[Product
Definition Center] which allows Fedora to maintain a database of each
Compose and all of it's contents in a way that can be queried and used
to make decisions in a programatic way.
===== The New Hotness
https://github.com/fedora-infra/the-new-hotness[The New Hotness] is a
http://www.fedmsg.com/en/latest/[fedmsg] consumer that listens to
release-monitoring.org and files bugzilla bugs in response (to notify
https://fedora-messaging.readthedocs.io/en/stable/[Fedora messaging] consumer
that listens to release-monitoring.org and files bugzilla bugs in response (to notify
packagers that they can update their packages).

114
modules/release_guide/pages/workflow_automation.adoc
View file

@ -1,114 +0,0 @@
== Fedora RelEng Workflow Automation
The Fedora RelEng Workflow Automation is a means to allow RelEng to
define a pattern by which Release Engineering work is automated in an
uniform fashion. The automation technology of choice is
https://ansible.com/[ansible] and the "workflow engine" is powered by
https://github.com/maxamillion/loopabull[loopabull], which is an event
loop that allows us to pass the information contained within a
http://www.fedmsg.com/en/latest/[fedmsg] and insert it into
https://ansible.com/[ansible]
https://docs.ansible.com/ansible/playbooks.html[playbooks]. This will
effectively create an event driven workflow that can take action
conditionally based on the contents of arbitrary
http://www.fedmsg.com/en/latest/[fedmsg] data.
Background on the topic can be found in the
https://fedoraproject.org/wiki/Changes/ReleaseEngineeringAutomationWorkflowEngine[Release
Engineering Automation Workflow Engine] Change proposal, as well as in
the https://pagure.io/releng-automation[releng-automation] pagure
repository.
=== RelEng Workflow Automation Architecture
By using http://www.fedmsg.com/en/latest/[fedmsg] as the source of
information feeding the event loop, we will configure
https://github.com/maxamillion/loopabull[loopabull] to listen for
specific
https://fedora-fedmsg.readthedocs.io/en/latest/topics.html[fedmsg
topics] which will correspond with https://ansible.com/[ansible]
https://docs.ansible.com/ansible/playbooks.html[playbooks]. When one of
the appropriate
https://fedora-fedmsg.readthedocs.io/en/latest/topics.html[fedmsg
topics] is encountered across the message bus, it's message payload is
then injected into the corresponding playbook as an extra set of
variables. A member of the Fedora Release Engineering Team can at that
point use this as a means to perform whatever arbitrary action or series
of actions they can otherwise perform with https://ansible.com/[ansible]
(including what we can enable via custom
https://docs.ansible.com/ansible/modules.html[modules]) based on the
input of the message payload.
The general overview of the architecture is below as well as a
description of how it works:
....
+------------+
| fedmsg |
| |
+---+--------+
| ^
| |
| |
| |
| |
| |
V |
+------------------+-----------------+
| |
| Release Engineering |
| Workflow Automation Engine |
| |
| - RabbitMQ |
| - fedmsg-rabbitmq-serializer |
| - loopabull |
| |
+----------------+-------------------+
|
|
|
|
V
+-----------------------+
| |
| composer/bodhi/etc |
| |
+-----------------------+
....
The flow of data will begin with an event somewhere in the
https://fedoraproject.org/wiki/Infrastructure[Fedora Infrastructure]
that sends a http://www.fedmsg.com/en/latest/[fedmsg] across the message
bus, then the messages will be taken in and serialized in to a
https://www.rabbitmq.com/[rabbitmq] worker queue using
https://pagure.io/fedmsg-rabbitmq-serializer[fedmsg-rabbitmq-serializer].
Then https://github.com/maxamillion/loopabull[loopabull] will be
listening to the rabbitmq worker queue for tasks to come in. Once a
message is recieved, it is processed and once it is either no-op'd or a
corresponding ansible playbook is run to completion, the message will be
`ack`'d and cleared from the worker queue. This will allow for us to
scale loopabull instances independently from the message queue as well
as ensure that work is not lost because of a downed or busy loopabull
instance. Also, as a point of note, the loopabull service instances will
be scaled using https://freedesktop.org/wiki/Software/systemd/[systemd]
https://fedoramagazine.org/systemd-template-unit-files/[unit templates].
Once a playbook has been triggered, it will run tasks on remote systems
on behalf of a loopabull automation user. These users can be privileged
if need be, however the scope of their privilege is based on the purpose
they serve. These user accounts are provisioned by the
https://fedoraproject.org/wiki/Infrastructure[Fedora Infrastructure]
Team based on the requirements of the
`RelEng Task Automation User Request Standard Operating
Procedure (SOP) <sop_requesting_task_automation_user>` document and
tasks are subject to code and security audit.
=== Fedora Lib RelEng
https://pagure.io/flr[Fedora Lib RelEng] (flr), is a library and set of
command line tools to expose the library that aims to provide re-usable
code for common tasks that need to be done in Release Engineering.
Combining this set of command line tools when necessary with the Release
Engineering Automation pipeline allows for easy separation of
permissions and responsibilities via sudo permissions on remote hosts.
This is explained in more detail on the project's pagure page.