Configuration — Fedora Messaging 1.1.0 documentation

# 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': 'my_queue',
            '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,
    }