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

Review fedmsg-new-message-type SOP

Browse source 
Signed-off-by: Michal Konečný <mkonecny@redhat.com>
This commit is contained in:
Michal Konečný 2021-08-19 13:46:13 +02:00
parent 20c82881ec
commit 3c43f7638d
2 changed files with 18 additions and 18 deletions
Download patch file Download diff file Expand all files Collapse all files

2
modules/sysadmin_guide/nav.adoc
View file

@ -29,7 +29,7 @@
** xref:fedmsg-gateway.adoc[fedmsg-gateway - SOP]
** xref:fedmsg-introduction.adoc[fedmsg introduction and basics - SOP]
** xref:fedmsg-irc.adoc[fedmsg-irc - SOP]
** xref:fedmsg-new-message-type.adoc[fedmsg-new-message-type - SOP in review ]
** xref:fedmsg-new-message-type.adoc[Adding a new fedmsg message type - SOP]
** xref:fedmsg-relay.adoc[fedmsg-relay - SOP in review ]
** xref:fedmsg-websocket.adoc[fedmsg-websocket - SOP in review ]
** xref:fedocal.adoc[fedocal - SOP in review ]

34
modules/sysadmin_guide/pages/fedmsg-new-message-type.adoc
View file

@ -6,8 +6,8 @@ First, figure out how you're going to publish the message? Is it from a
shell script or from a long running process?
If its from shell script, you need to just add a
[.title-ref]#fedmsg-logger# statement to the script. Remember to set the
[.title-ref]#--modname# and [.title-ref]#--topic# for your new message's
_fedmsg-logger_ statement to the script. Remember to set the
_--modname_ and _--topic_ for your new message's
fully-qualified topic.
If its from a python process, you need to just add a
@ -15,13 +15,13 @@ If its from a python process, you need to just add a
apply here.
If this is a short-lived python process, you'll want to add
[.title-ref]#active=True# to the call to `fedmsg.publish(..)`. This will
make the fedmsg lib "actively" reach out to our fedmsg-relay running on
busgateway01.
_active=True_ to the call to `fedmsg.publish(..)`. This will
make the _fedmsg_ lib "actively" reach out to our _fedmsg-relay_ running on
_busgateway01_.
If it is a long-running python process (like a WSGI thread), then you
don't need to pass any extra arguments. You don't want it to reach out
to the fedmsg-relay if possible. Your process will require that some
to the _fedmsg-relay_ if possible. Your process will require that some
"endpoints" are created for it in `/etc/fedmsg.d/`. More on that below.
== Supporting infrastructure
@ -31,18 +31,18 @@ key that can be read by the program to sign its message. If you don't
have a cert already, then you need to create it in the private repo. Ask
a sysadmin-main member.
Then you need to declare those certs in the [.title-ref]#fedmsg_certs#
Then you need to declare those certs in the _fedmsg_certs
data structure stored typically in our ansible `group_vars/` for this
service. Declare both the name of the cert, what group and user it
should be owned by, and in the `can_send:` section, declare the list of
topics that this cert should be allowed to publish.
If this is a long-running python process that is _not_ passing
[.title-ref]#active=True# to the call to
[.title-ref]#fedmsg.publish(..)#, then you have to also declare
_active=True_ to the call to
`fedmsg.publish(..)`, then you have to also declare
endpoints for it. You do that by specifying the `fedmsg_wsgi_procs` and
`fedmsg_wsgi_vars` in the `group_vars` for your service. The iptables
rules and fedmsg endpoints should be automatically created for you on
rules and _fedmsg_ endpoints should be automatically created for you on
the next playbook run.
== Supporting code
@ -50,9 +50,9 @@ the next playbook run.
At this point, you can push the change out to production and be
publishing messages "okay". Everything should be fine.
However, your message will show up blank in datagrepper, in IRC, and in
FMN, and everywhere else we try to render it. You _must_ then follow up
and write a new [.title-ref]#Processor# for it in the fedmsg_meta
However, your message will show up blank in _datagrepper_, in IRC, and in
_FMN_, and everywhere else we try to render it. You _must_ then follow up
and write a new _Processor_ for it in the _fedmsg_meta_
library we maintain:
https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure
@ -60,14 +60,14 @@ You also _must_ write a test case for it there. The docs listing all
topics we publish at http://fedora-fedmsg.rtfd.org/ is automatically
generated from the test suite. Please don't forget this.
Lastly, you should cut a release of fedmsg_meta and deploy it using the
[.title-ref]#playbooks/manual/upgrade/fedmsg.yml# playbook, which should
Lastly, you should cut a release of _fedmsg_meta_ and deploy it using the
`playbooks/manual/upgrade/fedmsg.yml` playbook, which should
update all the relevant hosts.
== Corner cases
If the process publishing the new message lives _outside_ our main
network, you have to jump through more hoops. Look at abrt, koschei, and
copr for examples of how to configure this (you need a special firewall
network, you have to jump through more hoops. Look at _abrt_, _koschei_, and
_copr_ for examples of how to configure this (you need a special firewall
rule, and they need to be configured to talk to our "inbound gateway"
running on the proxies.