Review fedmsg-new-message-type SOP

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

View file

@ -29,7 +29,7 @@
** xref:fedmsg-gateway.adoc[fedmsg-gateway - SOP] ** xref:fedmsg-gateway.adoc[fedmsg-gateway - SOP]
** xref:fedmsg-introduction.adoc[fedmsg introduction and basics - SOP] ** xref:fedmsg-introduction.adoc[fedmsg introduction and basics - SOP]
** xref:fedmsg-irc.adoc[fedmsg-irc - 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-relay.adoc[fedmsg-relay - SOP in review ]
** xref:fedmsg-websocket.adoc[fedmsg-websocket - SOP in review ] ** xref:fedmsg-websocket.adoc[fedmsg-websocket - SOP in review ]
** xref:fedocal.adoc[fedocal - SOP in review ] ** xref:fedocal.adoc[fedocal - SOP in review ]

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? shell script or from a long running process?
If its from shell script, you need to just add a If its from shell script, you need to just add a
[.title-ref]#fedmsg-logger# statement to the script. Remember to set the _fedmsg-logger_ statement to the script. Remember to set the
[.title-ref]#--modname# and [.title-ref]#--topic# for your new message's _--modname_ and _--topic_ for your new message's
fully-qualified topic. fully-qualified topic.
If its from a python process, you need to just add a 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. apply here.
If this is a short-lived python process, you'll want to add 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 _active=True_ to the call to `fedmsg.publish(..)`. This will
make the fedmsg lib "actively" reach out to our fedmsg-relay running on make the _fedmsg_ lib "actively" reach out to our _fedmsg-relay_ running on
busgateway01. _busgateway01_.
If it is a long-running python process (like a WSGI thread), then you 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 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. "endpoints" are created for it in `/etc/fedmsg.d/`. More on that below.
== Supporting infrastructure == 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 have a cert already, then you need to create it in the private repo. Ask
a sysadmin-main member. 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 data structure stored typically in our ansible `group_vars/` for this
service. Declare both the name of the cert, what group and user it 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 should be owned by, and in the `can_send:` section, declare the list of
topics that this cert should be allowed to publish. topics that this cert should be allowed to publish.
If this is a long-running python process that is _not_ passing If this is a long-running python process that is _not_ passing
[.title-ref]#active=True# to the call to _active=True_ to the call to
[.title-ref]#fedmsg.publish(..)#, then you have to also declare `fedmsg.publish(..)`, then you have to also declare
endpoints for it. You do that by specifying the `fedmsg_wsgi_procs` and 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 `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. the next playbook run.
== Supporting code == Supporting code
@ -50,9 +50,9 @@ the next playbook run.
At this point, you can push the change out to production and be At this point, you can push the change out to production and be
publishing messages "okay". Everything should be fine. publishing messages "okay". Everything should be fine.
However, your message will show up blank in datagrepper, in IRC, and in 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 _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 and write a new _Processor_ for it in the _fedmsg_meta_
library we maintain: library we maintain:
https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure 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 topics we publish at http://fedora-fedmsg.rtfd.org/ is automatically
generated from the test suite. Please don't forget this. generated from the test suite. Please don't forget this.
Lastly, you should cut a release of fedmsg_meta and deploy it using the Lastly, you should cut a release of _fedmsg_meta_ and deploy it using the
[.title-ref]#playbooks/manual/upgrade/fedmsg.yml# playbook, which should `playbooks/manual/upgrade/fedmsg.yml` playbook, which should
update all the relevant hosts. update all the relevant hosts.
== Corner cases == Corner cases
If the process publishing the new message lives _outside_ our main If the process publishing the new message lives _outside_ our main
network, you have to jump through more hoops. Look at abrt, koschei, and 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 _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" rule, and they need to be configured to talk to our "inbound gateway"
running on the proxies. running on the proxies.