Configuration¶
fedora-messaging can be configured with the
/etc/fedora-messaging/config.toml
file or by setting the
FEDORA_MESSAGING_CONF
environment variable to the path of the configuration
file.
Each configuration option has a default value.
Generic Options¶
These options apply to both consumers and publishers.
amqp_url¶
The AMQP broker to connect to. This URL should be in the format described by
the pika.connection.URLParameters
documentation. This defaults to
'amqp://?connection_attempts=3&retry_delay=5
.
tls¶
A dictionary of the TLS settings to use when connecting to the AMQP broker. The default is:
{
'ca_cert': '/etc/pki/tls/certs/ca-bundle.crt',
'keyfile': None,
'certfile': None,
}
The value of ca_cert
should be the path to a bundle of CA certificates used
to validate the certificate presented by the server. The ‘keyfile’ and
‘certfile’ values should be to the client key and client certificate to use
when authenticating with the broker.
Note
The broker URL must use the amqps
scheme. It is also possible to
provide these setting via the amqp_url
setting using a URL-encoded
JSON object. This setting is provided as a convenient way to avoid that.
client_properties¶
A dictionary that describes the client to the AMQP broker. This makes it easy to identify the application using a connection. The dictionary can contain arbitrary string keys and values. The default is:
{
'app': 'Unknown',
'product': 'Fedora Messaging with Pika',
'information': 'https://fedora-messaging.readthedocs.io/en/stable/',
'version': 'fedora_messaging-<version> with pika-<version>',
}
Apps should set the app
along with any additional keys they feel will help
administrators when debugging application connections. Do not use the
product
, information
, and version
keys as these will be set
automatically.
exchanges¶
A dictionary of exchanges that should be present in the broker. Each key should be an exchange name, and the value should be a dictionary with the exchange’s configuration. Options are:
type
- the type of exchange to create.durable
- whether or not the exchange should survive a broker restart.auto_delete
- whether or not the exchange should be deleted once no queues are bound to it.arguments
- dictionary of arbitrary keyword arguments for the exchange, which depends on the broker in use and its extensions.
For example:
{
'my_exchange': {
'type': 'fanout',
'durable': True,
'auto_delete': False,
'arguments': {},
},
}
The default is to ensure the ‘amq.topic’ topic exchange exists which should be sufficient for most use cases.
log_config¶
A dictionary describing the logging configuration to use, in a format accepted
by logging.config.dictConfig()
.
Publisher Options¶
The following configuration options are publisher-related.
publish_exchange¶
A string that identifies the exchange to publish to. The default is
amq.topic
.
Consumer Options¶
The following configuration options are consumer-related.
queues¶
A dictionary of queues that should be present in the broker. Each key should be a queue name, and the value should be a dictionary with the queue’s configuration. Options are:
durable
- whether or not the queue should survive a broker restart.auto_delete
- whether or not the queue should be deleted once the consumer disconnects.exclusive
- whether or not the queue is exclusive to the current connection.arguments
- dictionary of arbitrary keyword arguments for the queue, which depends on the broker in use and its extensions.
For example:
{
'my_queue': {
'durable': True,
'auto_delete': True,
'exclusive': False,
'arguments': {},
},
}
bindings¶
A list of dictionaries that define queue bindings to exchanges that consumers
will subscribe to. The queue
key is the queue’s name. The exchange
key
should be the exchange name and the routing_keys
key should be a list of
routing keys. For example:
[
{
'queue': 'name',
'exchange': 'amq.topic',
'routing_keys': ['topic1', 'topic2.#'],
},
]
This would create two bindings for the my_queue
queue, both to the
amq.topic
exchange. Consumers will consume from both queues.
callback¶
The Python path of the callback. This should be in the format
<module>:<object>
. For example, if the callback was called “my_callback”
and was located in the “my_module” module of the “my_package” package, the path
would be defined as my_package.my_module:my_callback
. The default is None.
Consult the Consumers documentation for details on implementing a callback.
consumer_config¶
A dictionary for the consumer to use as configuration. The consumer should access this key in its callback for any configuration it needs. Defaults to an empty dictionary.
qos¶
The quality of service settings to use for consumers. This setting is a
dictionary with two keys. prefetch_count
specifies the number of messages
to pre-fetch from the server. Pre-fetching messages improves performance by
reducing the amount of back-and-forth between client and server. The downside
is if the consumer encounters an unexpected problem, messages won’t be returned
to the queue and sent to a different consumer until the consumer times out.
prefetch_size
limits the size of pre-fetched messages (in bytes), with 0
meaning there is no limit. The default settings are:
{
'prefetch_count': 10,
'prefetch_size': 0,
}