Administration

System Requirements

Bodhi is currently only supported on active Fedora releases. It requires PostgreSQL >= 9.2.0.

Configuration

The Bodhi server is configured via an INI file found at /etc/bodhi/production.ini. Bodhi ships an example production.ini file that has all settings documented. Most settings have reasonable defaults if not defined, and the example settings file describes the default values in the commented settings. Here is a copy of the example config file with in-line documentation:

# The commented values in this config file represent the defaults.
#
# Note that under Python 3, you will need to use %% instead of % to put a literal % into the value
# of the config. Many settings use a %s for positional substitution, and those will need to be
# encoded as %%s.

[app:main]
use = egg:bodhi-server

##
## Messages
##

# The bodhi-approve-testing cron job will post this message as a comment from the bodhi user on
# updates that reach the required time in testing if they are not stable yet. Positional
# substitution is used, and the %%d will be replaced with the time in testing required for the
# update.
# testing_approval_msg = This update can be pushed to stable now if the maintainer wishes

# not_yet_tested_msg = This update has not yet met the minimum testing requirements defined in the <a href="https://fedoraproject.org/wiki/Package_update_acceptance_criteria">Package Update Acceptance Criteria</a>

# not_yet_tested_epel_msg = This update has not yet met the minimum testing requirements defined in the <a href="https://fedoraproject.org/wiki/EPEL_Updates_Policy">EPEL Update Policy</a>

# The comment that Bodhi will post on updates when a user posts negative karma.
# disable_automatic_push_to_stable = Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.


# Libravatar - If this is true libravatar will work as normal. Otherwise, all
# libravatar links will be replaced with the string "libravatar.org" so that
# the tests can still pass.
# libravatar_enabled = True

# Set this to true if you want to do federated dns libravatar lookup
# libravatar_dns = False

# If libravatar_dns is True, libravatar_prefer_tls will define what gets handed to
# libravatar.libravatar_url()'s https setting. It may be set to True or False, but defaults to None,
# which is effectively False.
# libravatar_prefer_tls = True

##
## Legal
##

# If you set this, Bodhi will display a link in the footer called "Legal" that points to the
# supplied link.
# legal_link =
# If you set this, Bodhi will display a link in the footer called "Privacy policy" that points to
# the supplied link. It will also link the privacy policy under the comment box.
# privacy_link =

# Cache_dir is used for writing temporary cache files used in the composer process.
# cache_dir =


# The URL for a datagrepper to use in various templates.
# badge_ids = binary-star|both-bull-and-self-transcended-tester-viii|catching-the-bull-tester-iv|corporate-drone|corporate-overlord|corporate-shill|discovery-of-the-footprints-tester-ii|in-search-of-the-bull-tester-i|is-this-thing-on-updates-testing-i|is-this-thing-on-updates-testing-ii|is-this-thing-on-updates-testing-iii|is-this-thing-on-updates-testing-iv|it-still-works!|like-a-rock-updates-stable-i|like-a-rock-updates-stable-ii|like-a-rock-updates-stable-iii|like-a-rock-updates-stable-iv|mic-check!-updates-testing-v|missed-the-train|override,-you-say|perceiving-the-bull-tester-iii|reaching-the-source-tester-ix|return-to-society-tester-x|riding-the-bull-home-tester-vi|stop-that-update!|take-this-and-call-me-in-the-morning|taming-the-bull-tester-v|tectonic!-updates-stable-v|the-bull-transcended-tester-vii|what-goes-around-comes-around-karma-i|what-goes-around-comes-around-karma-ii|what-goes-around-comes-around-karma-iii|what-goes-around-comes-around-karma-iv|white-hat|you-can-pry-it-from-my-cold,-dead-hands


##
## Testing
##

## Query the wiki for test cases
# query_wiki_test_cases = False
# wiki_url = https://fedoraproject.org/w/api.php
# test_case_base_url = https://fedoraproject.org/wiki/

# URL of the resultsdb for integrating checks and stuff
# resultsdb_api_url = https://taskotron.fedoraproject.org/resultsdb_api/

# Set this to True to enable gating based on policies enforced by Greenwave. If you set this to
# True, be sure to add a cron job to run the bodhi-check-policies CLI periodically.
# test_gating.required = False

# If this is set to a URL, a "More information about test gating" link will appear on update pages for users
# to click and learn more.
# test_gating.url =

# The API url of Greenwave.
# greenwave_api_url = https://greenwave-web-greenwave.app.os.fedoraproject.org/api/v1.0

# The URL for waiverdb's API
# waiverdb_api_url = https://waiverdb-web-waiverdb.app.os.fedoraproject.org/api/v1.0

# An access token used to authenticate to waiverdb
# waiverdb.access_token =

# Email domain to prepend usernames to
# default_email_domain = fedoraproject.org

# domain for generated message IDs
# message_id_email_domain = admin.fedoraproject.org

# Where to search for e-mail templates. Each release has a mail_template attribute that defines the
# name of a mail template, and Bodhi will look in the path defined by this setting to find the named
# template.
# mail.templates_basepath = bodhi:server/email/templates/


##
## Composer settings
##

# Where to initially compose repositories. You can use %(here)s to reference the location of this file.
# compose_dir =

# The max number of compose threads running at the same time
# max_concurrent_composes = 2

# Whether to clean old composes at the end of each run.
# clean_old_composes = true

# Where to symlink the latest repos by their tag name. You can use %(here)s to reference the
# location of this file.
# compose_stage_dir =

# Whether to wait for repomd.xml.asc signature files in the repo when composing updates or not
# wait_for_repo_sig = False

# The following jinja2 template variables are available for use to customize the Pungi configs and
# variants files to the Release and Updates:
#
#  * 'id': The id of the Release being composed.
#  * 'release': The Release being composed.
#  * 'request': The request being composed.
#  * 'updates': The Updates being composed.
#
# NOTE: The jinja2 configuration for these templates replaces the {'s and }'s with ['s and ]'.
# e.g.: a block becomes [% if <something %], and a variable is [[ varname ]].

# The base path where pungi configs will be stored. You will need to put variants.xml templates
# inside pungi.basepath as well. These templates will have access to the same template variables
# described above, and should be named variants.rpm.xml.j2 and variants.module.xml.j2, for RPM
# composes and module composes, respectively.
# pungi.basepath = /etc/bodhi

# The Pungi executable to use when composing.
# pungi.cmd = /usr/bin/pungi-koji

# The following settings reference filenames of jinja2 templates found in pungi.basepath to be used
# as Pungi configs for composing modules or RPMs (The RPM config includes dnf, yum, and atomic repos).
# pungi.conf.module = pungi.module.conf
# pungi.conf.rpm = pungi.rpm.conf

# A space separated list of extra arguments to be passed on to Pungi during composing.
# pungi.extracmdline =

# What to pass to Pungi's --label flag, which is metadata included in its composeinfo.json.
# pungi.labeltype = Update

# The skopeo executable to use to copy container images.
# You can put credentials for skopeo to use in $HOME/.docker/config.json
# https://github.com/projectatomic/skopeo#private-registries-with-authentication
#
# An alternative command is bodhi-skopeo-lite, installed by bodhi. It has various limitations
# (including not reading $HOME/.docker/config.json - it supports certificate authentication
# and credentials passed on the command line), but supports manifest lists and OCI image indexes,
# allowing copying multi-arch containers. See https://github.com/containers/image/pull/400 for
# work to add such support to skopeo proper.
#
# skopeo.cmd = /usr/bin/skopeo

# Comma separated list of extra flags to pass to the skopeo copy command.
# skopeo.extra_copy_flags =

# Container hostnames. You can specify a port as well, using the traditional syntax (i.e., localhost:5000).
# container.destination_registry = registry.fedoraproject.org
# container.source_registry = candidate-registry.fedoraproject.org


##
## Mirror settings
##
# file_url: Used in the repo metadata to set RPM URLs.
# file_url = https://download.fedoraproject.org/pub/fedora/linux/updates

# {release}_({version}_){request}_master_repomd: This is used by the composer to determine when a
#     primary architecture push has been synchronized to the master mirror for a given release and
#     request. The composer will verify that the checksum of repomd.xml at the master URL matches the
#     expected value, and will poll the URL until this test passes. Substitute release and request
#     for each release id (replacing -'s with _'s) and request (stable, testing). Used for the
#     arches listed in {release}_{version}_primary_arches when it is defined, else used for all
#     arches. You must put two %%s's in this setting - the first will be replaced with the release
#     version and the second will be replaced with the architecture.
# If a version of the option exists with a matching version, it has priority over one without.
# examples (these settings do not have defaults):
#     fedora_stable_master_repomd = http://download01.phx2.fedoraproject.org/pub/fedora/linux/updates/%%s/%%s/repodata/repomd.xml
#     fedora_28_stable_master_repomd = http://download01.phx2.fedoraproject.org/pub/fedora/linux/updates/%%s/Everything/%%s/repodata/repomd.xml
#     fedora_testing_master_repomd = http://download01.phx2.fedoraproject.org/pub/fedora/linux/updates/testing/%%s/%%s/repodata/repomd.xml
#     fedora_epel_stable_master_repomd = http://download01.phx2.fedoraproject.org/pub/epel/%%s/%%s/repodata/repomd.xml
#     fedora_epel_testing_master_repomd = http://download01.phx2.fedoraproject.org/pub/epel/testing/%%s/%%s/repodata/repomd.xml

# {release}_({version}_){request}_alt_master_repomd: This is used by the composer to determine when a
#     secondary architecture push has been synchronized to the master mirror for a given release and
#     request. The composer will verify that the checksum of repomd.xml at the master URL matches the
#     expected value, and will poll the URL until this test passes. Substitute release and request
#     for each release id (replacing -'s with _'s) and request (stable, testing). Used for the
#     arches not listed in {release}_{version}_primary_arches if it is defined. You must put two
#     %%s's in this setting - the first will be replaced with the release version and the second will
#     be replaced with the architecture.
# If a version of the option exists with a matching version, it has priority over one without.
# examples (these settings do not have defaults):
#     fedora_stable_alt_master_repomd = http://download01.phx2.fedoraproject.org/pub/fedora-secondary/updates/%%s/%%s/repodata/repomd.xml
#     fedora_28_stable_alt_master_repomd = http://download01.phx2.fedoraproject.org/pub/fedora-secondary/updates/%%s/Everything/%%s/repodata/repomd.xml
#     fedora_testing_alt_master_repomd = http://download01.phx2.fedoraproject.org/pub/fedora-secondary/updates/testing/%%s/%%s/repodata/repomd.xml


## The base url of this application
# base_address = https://admin.fedoraproject.org/updates/


## Primary architechures by release
##
## {release}_{version}_primary_arches: Releases that have alternative arches must define their
##      primary arches here. Any arches found during composing that are not present here are assumed
##      to be alternative arches. This is used during the wait_for_repo() step of the compose where
##      Bodhi polls the master repo to find out whether the compose has made it to the repo or not.
##      Bodhi looks for primary arches with the {release}_{request}_master_repomd setting above, and
##      for alternative arches at the {release}_{request}_alt_master_repomd setting above. If this
##      is not set, Bodhi will assume the release only has primary arches.
# example (not a default): fedora_26_primary_arches = armhfp x86_64

##
## Email setting
##

# The hostname of an SMTP server Bodhi can use to deliver e-mail.
# smtp_server =

# The updates system itself. This e-mail address is used as the From address for e-mails that Bodhi
# sends. It is also used as the username for Bugzilla if bugzilla_api_key is undefined and
# bodhi_password is defined.
# bodhi_email = updates@fedoraproject.org

# An API key that Bodhi should use when accessing Bugzilla. If set, the bodhi_password setting is
# ignored.
# bugzilla_api_key =

# This is the password used to access Bodhi's bugzilla account. Ignored if bugzilla_api_key is set.
# bodhi_password =

# The address that gets the requests
# release_team_address = bodhiadmin-members@fedoraproject.org

# Public lists where we send update announcements.
# These variables should be named per: Release.prefix_id.lower()_announce_list
# fedora_announce_list = package-announce@lists.fedoraproject.org
# fedora_test_announce_list = test@lists.fedoraproject.org
# fedora_epel_announce_list = epel-package-announce@lists.fedoraproject.org
# fedora_epel_test_announce_list = epel-devel@lists.fedoraproject.org

# Superuser groups
#
# Defined in and tied to the Fedora Account System (limited to 16 characters)
# admin_groups = proventesters security_respons bodhiadmin sysadmin-main

# Users that we don't want to show up in the "leaderboard(s)"
# stats_blacklist = bodhi anonymous autoqa taskotron

# A list of non-person users
# system_users = bodhi autoqa taskotron

# The max length for an update title before we truncate it in the web ui
# max_update_length_for_ui = 30

# The number of days used for calculating the 'top testers' metric
# top_testers_timeframe = 7

# These are the default requirements that we apply to packages and updates.
# Users have free-reign to override them for each kind of entity.  At
# the end of the day, we only consider the requirements defined by single
# updates themselves when gating in the backend composer process.
# site_requirements = dist.rpmdeplint

# Cache settings
# dogpile.cache.backend = dogpile.cache.dbm
# dogpile.cache.expiration_time = 100
# dogpile.cache.arguments.filename = /var/cache/bodhi-dogpile-cache.dbm

# If True (the default), warm up caches when the Bodhi process starts up. Otherwise, they will get warmed
# on first use.
# warm_cache_on_start = True

# Exclude sending emails to these users
# exclude_mail = autoqa taskotron

##
## Buildsystem settings
##

# What buildsystem do we want to use?  For development, we'll use a fake
# buildsystem that always does what we tell it to do.  For production, we'll
# want to use 'koji'.
# buildsystem = dev

# The base URL to Koji, used to construct HTML links to Koji builds in the web UI
# koji_web_url = https://koji.fedoraproject.org/koji/

# Koji's XML-RPC hub
# koji_hub = https://koji.stg.fedoraproject.org/kojihub


# URL of where users should go to set up their notifications
# fmn_url = https://apps.fedoraproject.org/notifications/


# Koji krb5
# krb_principal =
# krb_keytab =
# krb_ccache=

##
## ACL system
## Choices are 'pagure', which will query the pagure_url below, or 'dummy', which will
## always return guest credentials (used for local development).
##
# acl_system = dummy

# Add your username here to enable ACL rights in the development environment. Only has an effect if
# you are using the dummy acl_system.
# acl_dummy_committer =

##
## Pagure
##
# pagure_url = https://src.fedoraproject.org/pagure/

# This is the namespace where we expect to find the git sources for a Flatpak.
# The default - 'modules' instead of 'flatpaks' - is for backward compatibility
# pagure_flatpak_namespace = modules

##
## Product Definition Center (PDC)
##
# pdc_url = https://pdc.fedoraproject.org/


##
## Bug tracker settings
##
# Set this to bugzilla to turn on Bugzilla integration.
# bugtracker =

# A template that Bodhi will use when commenting on Bugzilla tickets when Updates that reference
# them are created. Positional substitution is used, and the three %%s's will be filled in with the
# update title, the release's long name, and the URL to the update, respectively.
# initial_bug_msg = %%s has been submitted as an update to %%s. %%s

# A template that Bodhi will use when commenting on Bugzilla tickets when Updates that reference
# them are marked stable. Positional substitution is used, and the first %%s will be filled in with
# the update title and the second will be filled in with the release's long name and the update
# status.
# stable_bug_msg = %%s has been pushed to the %%s repository. If problems still persist, please make note of it in this bug report.

# The following two templates are used to comment on Bugzilla tickets. %%s will be substituted with
# the update's URL. The first is used for all updates, unless the epel setting in defined, which
# will be used for all Updates on Releases that have an id_prefix of FEDORA-EPEL.
# testing_bug_msg =
#     See https://fedoraproject.org/wiki/QA:Updates_Testing for
#     instructions on how to install test updates.
#     You can provide feedback for this update here: %%s
# testing_bug_epel_msg =
#     See https://fedoraproject.org/wiki/QA:Updates_Testing for
#     instructions on how to install test updates.
#     You can provide feedback for this update here: %%s


##
## Bugzilla settings.
##

# The username/password for our bugzilla account comes
# from the bodhi_{email,password} fields.

# A URL to a Bugzilla instance's xmlrpc.cgi script for Bodhi to use.
# bz_server = https://bugzilla.redhat.com/xmlrpc.cgi

# A URL to a Bugzilla instance's REST api for Bodhi to use.
# bz_server_rest = https://bugzilla.redhat.com/rest/

# Bodhi will avoid touching bugs that are not against the following comma-separated products.
# Fedora's production Bodhi instance sets this to Fedora,Fedora EPEL
# bz_products =

# A template to use for links to Bugzilla tickets. %%s will be filled in with the bug number.
# buglink = https://bugzilla.redhat.com/show_bug.cgi?id=%%s


##
## Critical Path Packages
## https://fedoraproject.org/wiki/Critical_path_package
##

# You can allow Bodhi to query for critpath packages from the Product Definition
# Center by setting this value to `pdc`. If it isn't set, it'll just use the
# hardcoded list below.
# critpath.type =

# You can hardcode a list of critical path packages instead of using the PkgDB
# or PDC. This is used if critpath.type is not defined.
# critpath_pkgs =

# The number of admin approvals it takes to be able to push a critical path
# update to stable for a pending release.
# critpath.num_admin_approvals = 2

# The net karma required to submit a critical path update to a pending release.
# critpath.min_karma = 2

# Allow critpath to submit for stable after 2 weeks with no negative karma
# critpath.stable_after_days_without_negative_karma = 14

# The minimum amount of time an update must spend in testing before
# it can reach the stable repository
fedora.mandatory_days_in_testing = 7
fedora_epel.mandatory_days_in_testing = 14

##
## Release status
##

# You can define alternative policies than the defaults for specific Releases by defining a setting
# of the form Release.name.status (with -'s removed from the name). You can set the status to any
# string you like, and then for each status, you can override the mandatory days in testing, the
# critpath number of admin approvals, and the critpath minimum karma. For example, if we want to set
# Fedora 28 as a pre-beta, and we want it to have different rules in pre-beta and post-beta, we
# could do something like this:
#f28.status = pre_beta
#f28.pre_beta.mandatory_days_in_testing = 3
#f28.pre_beta.critpath.num_admin_approvals = 0
#f28.pre_beta.critpath.min_karma = 1
#f28.post_beta.mandatory_days_in_testing = 7
#f28.post_beta.critpath.num_admin_approvals = 0
#f28.post_beta.critpath.min_karma = 2


##
## Buildroot Override
##

# Maximum number of days a buildroot override may expire in, from creation time.
# buildroot_limit = 31


##
## Groups
##

# FAS Groups that we want to pay attention to
# When a user logs in, bodhi will look for any of these groups and associate
# them with the user. They will then appear as the users effective principals in
# the format "group:groupname" and can be used in Pyramid ACE's.
#
# Defined in and tied to the Fedora Account System (limited to 16 characters)
# important_groups = proventesters provenpackager releng security_respons packager bodhiadmin

# Groups that can push updates for any package
#
# Defined in and tied to the Fedora Account System (limited to 16 characters)
# admin_packager_groups = provenpackager releng security_respons

# User must be a member of this group to submit updates
# mandatory_packager_groups = packager


##
## updateinfo.xml configuration
##
# updateinfo_rights = Copyright (C) {CURRENT_YEAR} Red Hat, Inc. and others.

##
## Authentication & Authorization
##

# pyramid.openid settings.
# openid.success_callback = bodhi.server.security:remember_me
# openid.provider = https://id.fedoraproject.org/openid/
# openid.url = https://id.fedoraproject.org/
# openid_template = {username}.id.fedoraproject.org
# openid.sreg_required = email nickname
# If this is undefined, Bodhi will concatenate the groups listed in the following other settings
# from this file: important_groups, admin_packager_groups, mandatory_packager_groups, and
# admin_groups. You likely want this default, but can override it here if you know what you are
# doing. You can also override it here if you do not know what you are doing, but that would be
# inadvisable.
# openid.groups = DEFAULT_DOCUMENTED_ABOVE


# CORS allowed origins for cornice services
# This can be wide-open.  read-only, we don't care as much about.
cors_origins_ro = *
# This should be more locked down to avoid cross-site request forgery.
cors_origins_rw = https://bodhi.fedoraproject.org

cors_connect_src = https://*.fedoraproject.org/ wss://hub.fedoraproject.org:9939/


##
## Pyramid settings
##
pyramid.reload_templates = true
pyramid.debug_authorization = true
pyramid.debug_notfound = true
pyramid.debug_routematch = true
pyramid.default_locale_name = en

debugtoolbar.hosts = 127.0.0.1 ::1

##
## Database
##
# This must be a PostgreSQL database. You can encode a username and password in the URL. For
# example, postgresql://username:password@hostname/database_name
# sqlalchemy.url = postgresql://localhost/bodhi

##
## Templates
##
# Where Bodhi's templates are stored. You likely don't want or need to adjust this setting.
# mako.directories = bodhi:server/templates

##
## Authentication & Sessions
##

# CHANGE THESE IN PRODUCTION!
# authtkt.secret = CHANGEME
# session.secret = CHANGEME
# authtkt.secure = True
# How long should an authorization ticket be valid for, in seconds? Defaults to one day.
# authtkt.timeout = 86400


# pyramid_beaker
session.type = file
session.data_dir = %(here)s/data/sessions/data
session.lock_dir = %(here)s/data/sessions/lock
session.key = mykey
session.cookie_on_exception = true
# Tell the browser to only send the cookie over TLS
session.secure = true
# Create a cookie that is only valid for one day
session.timeout = 86400
cache.regions = default_term, second, short_term, long_term
cache.type = memory
cache.second.expire = 1
cache.short_term.expire = 60
cache.default_term.expire = 300
cache.long_term.expire = 3600

# Celery configuration file
celery_config = /etc/bodhi/celeryconfig.py


[server:main]
use = egg:waitress#main
host = 0.0.0.0
port = 6543

[pshell]
m = bodhi.server.models
#db = bodhi.server.util.pshell_db
t = transaction


# Begin logging configuration

[loggers]
keys = root, bodhi, sqlalchemy, celery, celery_worker_job

[handlers]
keys = console

[formatters]
keys = generic

[logger_root]
level = INFO
handlers = console

[logger_bodhi]
level = DEBUG
handlers =
qualname = bodhi

[logger_sqlalchemy]
level = INFO
handlers =
qualname = sqlalchemy.engine
# "level = INFO" logs SQL queries.
# "level = DEBUG" logs SQL queries and results.
# "level = WARN" logs neither.  (Recommended for production systems.)

[logger_celery]
level = INFO
handlers =
qualname = celery

[logger_celery_worker_job]
level = ERROR
handlers =
qualname = celery.worker.job
propagate = 1

[handler_console]
class = StreamHandler
args = (sys.stderr,)
level = NOTSET
formatter = generic

[formatter_generic]
format = %(asctime)s %(levelname)-5.5s [%(name)s][%(threadName)s] %(message)s

# End logging configuration

Logging

The example configuration above includes an example default logging configuration. However, you may wish to do something more advanced, such as e-mail error messages to an address with rate limiting. Bodhi provides a rate limiting Python logging Filter at `bodhi.server.logging.RateLimiter`.

Unfortunately, it is not possible to use Python logging filters with Pyramid’s ini file, so if you wish to use Bodhi’s `RateLimiter` log filter, you will need to configure Pyramid to use pyramid_sawing so that it can use more advanced logging configuration. As a quick example, you might put something like this into /etc/bodhi/production.ini to configure Pyramid to use `pyramid_sawing` and to look for a logging config at `/etc/bodhi/logging.yaml`:

pyramid.includes =
    pyramid_sawing
pyramid_sawing.file = /etc/bodhi/logging.yaml

Then you could configure all of you logging in `/etc/bodhi/logging.yaml`. Here is a snippet you could use in that file to get Bodhi to e-mail error logs, but to limit them to one e-mail per hour per process per spot in the code that logs errors:

---
version: 1

formatters:
  generic:
    format: '%(asctime)s %(levelname)-5.5s [%(name)s][%(threadName)s] %(message)s'
filters:
  rate_limit:
    (): bodhi.server.logging.RateLimiter
    rate: 3600
handlers:
  smtp:
    class: logging.handlers.SMTPHandler
    mailhost: "smtp.example.com"
    fromaddr: "bodhi@example.com"
    toaddrs:
        - "admin@example.com"
    subject: "Bodhi had a sad"
    level: ERROR
    formatter: generic
    filters: [rate_limit]
loggers:
  bodhi:
    level: INFO
    handlers: [smtp]
    propagate: 0
root:
  level: NOTSET
  handlers: []

You can read more detail about the `RateLimiter` below:

class bodhi.server.logging.RateLimiter(rate: int = 3600)

Bases: logging.Filter

Log filter that rate-limits logs based on time.

The rate limit is applied to records by filename and line number.

Filters can be applied to handlers and loggers. Configuring this via dictConfig is possible, but has somewhat odd syntax:

log_config = {
    "filters": {
        "60_second_filter": {
            "()": "fedmsg_migration_tools.filters.RateLimiter",
            "rate": "60"
        }
    }
    "handlers": {
        "rate_limited": {
            "filters": ["60_second_filter"],
            ...
        }
    }
    "loggers": {
        "fedmsg_migration_tools": {
            "filters": ["60_second_filter"],
            ...
        }
    }
}

This was shamelessly stolen from https://github.com/fedora-infra/fedmsg-migration-tools/blob/0cafc8f/fedmsg_migration_tools/filters.py which is also licensed GPLv2+.

rate

How often, in seconds, to allow records. Defaults to hourly.

__init__(rate: int = 3600)

Initialize the log filter.

Parameters

rate – How often, in seconds, to allow records. Defaults to hourly.

filter(record: logging.LogRecord) → bool

Record call sites and filter based on time.

Parameters

record – The log record we are filtering on.

Returns

True if the record should be emitted, False otherwise.

Components

CLI tools

See the Man pages documentation for a list of CLI tools that come with Bodhi.

Web Server

Bodhi has a web server component that runs its REST API and serves the web interface.

Message Consumers

The following sections document the list of messaging consumers.

Automatic updates

This consumer will create updates automatically when builds are tagged to a Release’s candidate tag, if the Release associated with that tag is configured to do so by having its create_automatic_updates boolean set to True.

Composer

Bodhi has a process called the “composer” that is responsible for generating the repositories that move packages along the path to their destiny. For each release, there are two composes that get run, one for the release’s testing repository, and the other for the release’s stable repository.

Administrators can use the bodhi-push tool to start composes. To view the status of composes once they have been started, users can use bodhi composes list or they can visit the /composes/ URL on the server. Composes can be in the following states:

• requested: The compose has been created by bodhi-push, but the composer has not yet started working on the task.

• pending: The composer has received the task and will start it when it has free threads to do so.

• initializing: The composer has started working on the task.

• updateinfo: The composer is generating the updateinfo.xml file.

• punging: The composer is waiting for Pungi to finish creating the repository.

• syncing_repo: The composer is polling the master mirror and waiting until the newly composed repository is present there.

• notifying: The composer is sending out notifications about the updates.

• success: The composer has successfully finished the task. This state does not last long as the records of successful composes are deleted shortly after reaching this state.

• failed: The composer has failed. An administrator will usually have to inspect the error message associated with the compose to determine what action to take to correct the problem, and then the compose can be resumed with bodhi-push.

• signing_repo: The composer is waiting on the repository to be signed.

• cleaning: The composer is cleaning up old composes. This state only occurs if clean_old_composes is set to True in the settings.

Greenwave Handler

Bodhi’s greenwave handler watches for messages sent from greenwave about bodhi updates that have been tested. When a message is recieved, the appropriate update is updated with the greenwave test status.

Signed Handler

Bodhi’s signed handler is responsible for watching for messages from Robosignatory when it signs builds, and marking those builds as signed in the Bodhi database.

Update Handler

Bodhi’s update handler watches for messages sent from the web server when updates are created or edited. When it sees these messages, it does background tasks, such as querying bugzilla to determine the titles on associated tickets, or querying the Wiki to retrieve test case information.