Review fedmsg-relay SOP
Remove the link to topology diagram, it's not working anymore. And I didn't find it in the documentation. Signed-off-by: Michal Konečný <mkonecny@redhat.com>
This commit is contained in:
parent
3c43f7638d
commit
d5b724b2d8
2 changed files with 12 additions and 14 deletions
|
@ -30,7 +30,7 @@
|
||||||
** 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[Adding a new fedmsg message type - SOP]
|
** 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]
|
||||||
** 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 ]
|
||||||
** xref:fedora-releases.adoc[fedora-releases - SOP in review ]
|
** xref:fedora-releases.adoc[fedora-releases - SOP in review ]
|
||||||
|
|
|
@ -15,44 +15,42 @@ Purpose::
|
||||||
|
|
||||||
== Description
|
== Description
|
||||||
|
|
||||||
fedmsg-relay is running on app01, which is a bad choice. We should look
|
_fedmsg-relay_ is running on _app01_, which is a bad choice. We should look
|
||||||
to move it to a more isolated place in the future. busgateway01 would be
|
to move it to a more isolated place in the future. _busgateway01_ would be
|
||||||
a better choice.
|
a better choice.
|
||||||
|
|
||||||
"Ephemeral" scripts like `pkgdb2branch.py`, the post-receive git hook on
|
"Ephemeral" scripts like `pkgdb2branch.py`, the post-receive git hook on
|
||||||
pkgs01, and anywhere fedmsg-logger is used all depend on fedmsg-relay.
|
_pkgs01_, and anywhere _fedmsg-logger_ is used all depend on _fedmsg-relay_.
|
||||||
Instead of emitting messages "directly" to the rest of the bus, they use
|
Instead of emitting messages "directly" to the rest of the bus, they use
|
||||||
fedmsg-relay as an intermediary.
|
fedmsg-relay as an intermediary.
|
||||||
|
|
||||||
Check that fedmsg-relay is running by looking for it in the process
|
Check that _fedmsg-relay_ is running by looking for it in the process
|
||||||
list. You can restart it in the standard way with
|
list. You can restart it in the standard way with
|
||||||
`sudo service fedmsg-relay restart`. Check for its logs in
|
`sudo service fedmsg-relay restart`. Check for its logs in
|
||||||
`/var/log/fedmsg/fedmsg-relay.log`
|
`/var/log/fedmsg/fedmsg-relay.log`
|
||||||
|
|
||||||
Ephemeral scripts know where the fedmsg-relay is by looking for the
|
Ephemeral scripts know where the _fedmsg-relay_ is by looking for the
|
||||||
relay_inbound and relay_outbound values in the global fedmsg config.
|
relay_inbound and relay_outbound values in the global fedmsg config.
|
||||||
|
|
||||||
== But What is it Doing? And Why?
|
== But What is it Doing? And Why?
|
||||||
|
|
||||||
The fedmsg bus is designed to be "passive" in its normal operation. A
|
The _fedmsg_ bus is designed to be "passive" in its normal operation. A
|
||||||
mod_wsgi process under httpd sets up its fedmsg publisher socket to
|
_mod_wsgi_ process under _httpd_ sets up its _fedmsg_ publisher socket to
|
||||||
passively emit messages on a certain port. When some other service wants
|
passively emit messages on a certain port. When some other service wants
|
||||||
to receive these messages, it is up to that service to know where
|
to receive these messages, it is up to that service to know where
|
||||||
mod_wsgi is emitting and to actively connect there. In this way,
|
_mod_wsgi_ is emitting and to actively connect there. In this way,
|
||||||
emitting is passive and listening is active.
|
emitting is passive and listening is active.
|
||||||
|
|
||||||
We get a problem when we have a one-off or "ephemeral" script that is
|
We get a problem when we have a one-off or "ephemeral" script that is
|
||||||
not a long-running process -- a script like pkgdb2branch which is run
|
not a long-running process -- a script like _pkgdb2branch_ which is run
|
||||||
when a user runs it and which ends shortly after. Listeners who want
|
when a user runs it and which ends shortly after. Listeners who want
|
||||||
these scripts messages will find that they are usually not available
|
these scripts messages will find that they are usually not available
|
||||||
when they try to connect.
|
when they try to connect.
|
||||||
|
|
||||||
To solve this problem, we introduced the "fedmsg-relay" daemon which is
|
To solve this problem, we introduced the "_fedmsg-relay_" daemon which is
|
||||||
a kind of "passive"-to-"passive" adaptor. It binds to an outbound port
|
a kind of "passive"-to-"passive" adaptor. It binds to an outbound port
|
||||||
on one end where it will publish messages (like normal) but it also
|
on one end where it will publish messages (like normal) but it also
|
||||||
binds to an another port where it listens passively for inbound
|
binds to an another port where it listens passively for inbound
|
||||||
messages. Ephemeral scripts then actively connect to the passive inbound
|
messages. Ephemeral scripts then actively connect to the passive inbound
|
||||||
port of the fedmsg-relay to have their payloads echoed on the
|
port of the _fedmsg-relay_ to have their payloads echoed on the
|
||||||
bus-proper.
|
bus-proper.
|
||||||
|
|
||||||
See http://fedmsg.readthedocs.org/en/latest/topology/ for a diagram.
|
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue