osloconfig(1)
| OSLOCONFIG(1) | oslo.config | OSLOCONFIG(1) |
NAME
osloconfig - oslo.config 9.7.1
An OpenStack library for parsing configuration options from the command line and configuration files.
CONTENTS
Configuration Guide
oslo.config Quick Start!
Are you brand new to oslo.config? This brief tutorial will get you started understanding some of the fundamentals.
Prerequisites
- A plain text editor or Python-enabled IDE
- A Python interpreter
- A command shell from which the interpreter can be invoked
- The oslo_config library in your Python path.
Test Script
Put this in a file called oslocfgtest.py.
# The sys module lets you get at the command line arguments.
import sys
# Load up the cfg module, which contains all the classes and methods
# you'll need.
from oslo_config import cfg
# Define an option group
grp = cfg.OptGroup('mygroup')
# Define a couple of options
opts = [cfg.StrOpt('option1'),
cfg.IntOpt('option2', default=42)]
# Register your config group
cfg.CONF.register_group(grp)
# Register your options within the config group
cfg.CONF.register_opts(opts, group=grp)
# Process command line arguments. The arguments tell CONF where to
# find your config file, which it loads and parses to populate itself.
cfg.CONF(sys.argv[1:])
# Now you can access the values from the config file as
# CONF.<group>.<opt>
print("The value of option1 is %s" % cfg.CONF.mygroup.option1)
print("The value of option2 is %d" % cfg.CONF.mygroup.option2)
Conf File
Put this in a file called oslocfgtest.conf in the same directory as oslocfgtest.py.
[mygroup] option1 = foo # Comment out option2 to test the default value # option2 = 123
Run It!
From your command shell, in the same directory as your script and conf, invoke:
python oslocfgtest.py --config-file oslocfgtest.conf
Revel in the output being exactly as expected. If you've done everything right, you should see:
The value of option1 is foo The value of option2 is 42
Now go play with some more advanced option settings!
Configuration file format
OpenStack uses the INI file format for configuration files. An INI file is a simple text file that specifies options as key=value pairs, grouped into sections. The DEFAULT section contains most of the configuration options. Lines starting with a hash sign (#) are comment lines. For example:
[DEFAULT] # Print debugging output (set logging level to DEBUG instead # of default WARNING level). (boolean value) debug = true [database] # The SQLAlchemy connection string used to connect to the # database (string value) connection = mysql+pymysql://keystone:KEYSTONE_DBPASS@controller/keystone
Options can have different types for values. The comments in the sample config files always mention these and the tables mention the Opt value as first item like (BoolOpt) Toggle.... The following types are used by OpenStack:
- boolean value (BoolOpt)
- Enables or disables an option. The allowed values are true and false.
# Enable the experimental use of database reconnect on # connection lost (boolean value) use_db_reconnect = false
- floating point value (FloatOpt)
- A floating point number like 0.25 or 1000.
# Sleep time in seconds for polling an ongoing async task # (floating point value) task_poll_interval = 0.5
- integer value (IntOpt)
- An integer number is a number without fractional components, like 0 or 42.
# The port which the OpenStack Compute service listens on. # (integer value) compute_port = 8774
- IP address (IPOpt)
- An IPv4 or IPv6 address.
# Address to bind the server. Useful when selecting a particular network # interface. (ip address value) bind_host = 0.0.0.0
- key-value pairs (DictOpt)
- A key-value pairs, also known as a dictionary. The key value pairs are separated by commas and a colon is used to separate key and value. Example: key1:value1,key2:value2.
# Parameter for l2_l3 workflow setup. (dict value) l2_l3_setup_params = data_ip_address:192.168.200.99, \
data_ip_mask:255.255.255.0,data_port:1,gateway:192.168.200.1,ha_port:2
- list value (ListOpt)
- Represents values of other types, separated by commas. As an example, the following sets allowed_rpc_exception_modules to a list containing the four elements oslo.messaging.exceptions, nova.exception, cinder.exception, and exceptions:
# Modules of exceptions that are permitted to be recreated # upon receiving exception data from an rpc call. (list value) allowed_rpc_exception_modules = oslo.messaging.exceptions,nova.exception
- multi valued (MultiStrOpt)
- A multi-valued option is a string value and can be given more than once, all values will be used.
# Driver or drivers to handle sending notifications. (multi valued) notification_driver = nova.openstack.common.notifier.rpc_notifier notification_driver = ceilometer.compute.nova_notifier
- port value (PortOpt)
- A TCP/IP port number. Ports can range from 1 to 65535.
# Port to which the UDP socket is bound. (port value) # Minimum value: 1 # Maximum value: 65535 udp_port = 4952
- string value (StrOpt)
- Strings can be optionally enclosed with single or double quotes.
# The format for an instance that is passed with the log message. # (string value) instance_format = "[instance: %(uuid)s] "
Sections
Configuration options are grouped by section. Most configuration files support at least the following sections:
- [DEFAULT]
- Contains most configuration options. If the documentation for a configuration option does not specify its section, assume that it appears in this section.
- [database]
- Configuration options for the database that stores the state of the OpenStack service.
Substitution
The configuration file supports variable substitution. After you set a configuration option, it can be referenced in later configuration values when you precede it with a $, like $OPTION.
The following example uses the values of rabbit_host and rabbit_port to define the value of the rabbit_hosts option, in this case as controller:5672.
# The RabbitMQ broker address where a single node is used. # (string value) rabbit_host = controller # The RabbitMQ broker port where a single node is used. # (integer value) rabbit_port = 5672 # RabbitMQ HA cluster host:port pairs. (list value) rabbit_hosts = $rabbit_host:$rabbit_port
To avoid substitution, escape the $ with $$ or \$. For example, if your LDAP DNS password is $xkj432, specify it, as follows:
ldap_dns_password = $$xkj432
The code uses the Python string.Template.safe_substitute() method to implement variable substitution. For more details on how variable substitution is resolved, see https://docs.python.org/2/library/string.html#template-strings and PEP 292.
Whitespace
To include whitespace in a configuration value, use a quoted string. For example:
ldap_dns_password='a password with spaces'
Define an alternate location for a config file
Most services and the *-manage command-line clients load the configuration file. To define an alternate location for the configuration file, pass the --config-file CONFIG_FILE parameter when you start a service or call a *-manage command.
Changing config at runtime
OpenStack Newton introduces the ability to reload (or 'mutate') certain configuration options at runtime without a service restart. The following projects support this:
- •
- Compute (nova)
Check individual options to discover if they are mutable.
In practice
A common use case is to enable debug logging after a failure. Use the mutable config option called 'debug' to do this (providing log_config_append has not been set). An admin user may perform the following steps:
- 1.
- Log onto the compute node.
- 2.
- Edit the config file (EG nova.conf) and change 'debug' to True.
- 3.
- Send a SIGHUP signal to the nova process (For example, pkill -HUP nova).
A log message will be written out confirming that the option has been changed. If you use a CMS like Ansible, Chef, or Puppet, we recommend scripting these steps through your CMS.
Configuration Options from oslo.config
When loading values from the sources defined by the following options, the precedence is as follows:
- 1.
- Command Line
- 2.
- Environment Variables
- 3.
- Config Files from --config-dir [1]
- 4.
- Config Files from --config-file
- 5.
- Pluggable Config Sources
If a value is specified in multiple locations, the location used will be the one higher in the list. For example, if a value is specified both on the command line and in an environment variable, the value from the command line will be the one returned.
- [1]
- Files in a config dir are parsed in alphabetical order. Later files take precedence over earlier ones.
DEFAULT
- config_file
- Type
- list of filenames
- Default
- ['~/.project/project.conf', '~/project.conf', '/etc/project/project.conf', '/etc/project.conf']
Path to a config file to use. Multiple config files can be specified, with values in later files taking precedence. Defaults to the value above. This option must be set from the command-line.
- config_dir
- Type
- list of directory names
- Default
- ['~/.project/project.conf.d/', '~/project.conf.d/', '/etc/project/project.conf.d/', '/etc/project.conf.d/']
Path to a config directory to pull *.conf files from. This file set is sorted, so as to provide a predictable parse order if individual options are over-ridden. The set is parsed after the file(s) specified via previous --config-file, arguments hence over-ridden options in the directory take precedence. This option must be set from the command-line.
- config_source
- Type
- list
- Default
- []
Lists configuration groups that provide more details for accessing configuration settings from locations other than local files.
sample_remote_file_source
Example of using a remote_file source
remote_file: A backend driver for remote files served through http[s].
- Required options:
- •
- uri: URI containing the file location.
- Non-required options:
- •
- ca_path: The path to a CA_BUNDLE file or directory with
- certificates of trusted CAs.
- •
- client_cert: Client side certificate, as a single file path
- containing either the certificate only or the private key and the certificate.
- •
- client_key: Client side private key, in case client_cert is
- specified but does not includes the private key.
- driver
- Type
- string
- Default
- remote_file
This option has a sample default set, which means that its actual default value may vary from the one documented above.
The name of the driver that can load this configuration source.
- uri
- Type
- URI
- Default
- https://example.com/my-configuration.ini
This option has a sample default set, which means that its actual default value may vary from the one documented above.
Required option with the URI of the extra configuration file's location.
- ca_path
- Type
- string
- Default
- /etc/ca-certificates
This option has a sample default set, which means that its actual default value may vary from the one documented above.
The path to a CA_BUNDLE file or directory with certificates of trusted CAs.
- client_cert
- Type
- string
- Default
- /etc/ca-certificates/service-client-keystore
This option has a sample default set, which means that its actual default value may vary from the one documented above.
Client side certificate, as a single file path containing either the certificate only or the private key and the certificate.
- client_key
- Type
- string
- Default
- <None>
Client side private key, in case client_cert is specified but does not includes the private key.
- timeout
- Type
- string
- Default
- 60
Timeout is the number of seconds the request will wait for your client to establish a connection to a remote machine call on the socket.
Configuration Source Drivers
In addition to command line options and configuration files, oslo.config can access configuration settings in other locations using drivers to define new sources.
remote_file
A backend driver for remote files served through http[s].
- Required options:
- •
- uri: URI containing the file location.
- Non-required options:
- •
- ca_path: The path to a CA_BUNDLE file or directory with
- certificates of trusted CAs.
- •
- client_cert: Client side certificate, as a single file path
- containing either the certificate only or the private key and the certificate.
- •
- client_key: Client side private key, in case client_cert is
- specified but does not includes the private key.
oslo.config Reference Guide
oslo_config
oslo_config package
Subpackages
oslo_config.sources package
Module contents
Oslo.config's primary source of configuration data are plaintext, INI-like style, configuration files. With the addition of backend drivers support, it is possible to store configuration data in different places and with different formats, as long as there exists a proper driver to connect to those external sources and provide a way to fetch configuration values from them.
A backend driver implementation is divided in two main classes, a driver class of type ConfigurationSourceDriver and a configuration source class of type ConfigurationSource.
IMPORTANT: At this point, all backend drivers are only able to provide immutable values. This protects applications and services from having options in external sources mutated when they reload configuration files.
- class oslo_config.sources.ConfigurationSource
- Bases: object
A configuration source option for oslo.config.
A configuration source is able to fetch configuration values based on a (group, option) key from an external source that supports key-value mapping such as INI files, key-value stores, secret stores, and so on.
- abstract get(group_name, option_name, opt)
- Return the value of the option from the group.
- Parameters
- group_name (str) -- Name of the group.
- option_name (str) -- Name of the option.
- opt (Opt) -- The option definition.
- Returns
- A tuple (value, location) where value is the option value or oslo_config.sources._NoValue if the (group, option) is not present in the source, and location is a LocationInfo.
- class oslo_config.sources.ConfigurationSourceDriver
- Bases: object
A backend driver option for oslo.config.
For each group name listed in config_source in the DEFAULT group, a ConfigurationSourceDriver is responsible for creating one new instance of a ConfigurationSource. The proper driver class to be used is selected based on the driver option inside each one of the groups listed in config_source and loaded through entry points managed by stevedore using the namespace oslo.config.driver:
[DEFAULT] config_source = source1 config_source = source2 ... [source1] driver = remote_file ... [source2] driver = castellan ...
Each specific driver knows all the available options to properly instatiate a ConfigurationSource using the values comming from the given group in the open_source_from_opt_group() method and is able to generate sample config through the list_options_for_discovery() method.
- abstract list_options_for_discovery()
- Return the list of options available to configure a new source.
Drivers should advertise all supported options in this method for the purpose of sample generation by oslo-config-generator.
For an example on how to implement this method you can check the remote_file driver at oslo_config.sources._uri.URIConfigurationSourceDriver.
- Returns
- a list of supported options of a ConfigurationSource.
- abstract open_source_from_opt_group(conf, group_name)
- Return an open configuration source.
Uses group_name to find the configuration settings for the new source and then open the configuration source and return it.
If a source cannot be open, raises an appropriate exception.
- Parameters
- conf (ConfigOpts) -- The active configuration option handler from which to seek configuration values.
- group_name (str) -- The configuration option group name where the options for the source are stored.
- Returns
- an instance of a subclass of ConfigurationSource
Submodules
oslo_config.cfg module
Primary module in oslo_config.
- exception oslo_config.cfg.ArgsAlreadyParsedError(msg=None)
- Bases: Error
Raised if a CLI opt is registered after parsing.
- class oslo_config.cfg.BoolOpt(name, **kwargs)
- Bases: Opt
Boolean options.
Bool opts are set to True or False on the command line using --optname or --nooptname respectively.
In config files, boolean values are cast with Boolean type.
- Parameters
- name -- the option's name
- **kwargs -- arbitrary keyword arguments passed to Opt
- exception oslo_config.cfg.ConfigDirNotFoundError(config_dir)
- Bases: Error
Raised if the requested config-dir is not found.
- exception oslo_config.cfg.ConfigFileParseError(config_file, msg)
- Bases: Error
Raised if there is an error parsing a config file.
- exception oslo_config.cfg.ConfigFileValueError(msg=None)
- Bases: ConfigSourceValueError
Raised if a config file value does not match its opt type.
- exception oslo_config.cfg.ConfigFilesNotFoundError(config_files)
- Bases: Error
Raised if one or more config files are not found.
- exception oslo_config.cfg.ConfigFilesPermissionDeniedError(config_files)
- Bases: Error
Raised if one or more config files are not readable.
- class oslo_config.cfg.ConfigOpts
- Bases: Mapping
Config options which may be set on the command line or in config files.
ConfigOpts is a configuration option manager with APIs for registering option schemas, grouping options, parsing option values and retrieving the values of options.
It has built-in support for config_file and config_dir options.
Changed in version 9.5.0: Added shell-completion option for generate a shell completion script.
- class GroupAttr(conf, group)
- Bases: Mapping
Helper class.
Represents the option values of a group as a mapping and attributes.
- class StrSubWrapper(conf, group=None, namespace=None)
- Bases: object
Helper class.
Exposes opt values as a dict for string substitution.
- class SubCommandAttr(conf, group, dest)
- Bases: object
Helper class.
Represents the name and arguments of an argparse sub-parser.
- class Template(template)
- Bases: Template
- idpattern = '[_a-z][\\._a-z0-9]*'
- pattern = re.compile('\n \\$(?:\n (?P<escaped>\\$) | # Escape sequence of two delimiters\n (?P<named>[_a-z][\\._a-z0-9]*) | # delimiter and a Python identifier\n , re.IGNORECASE|re.VERBOSE)
- clear()
- Reset the state of the object to before options were registered.
This method removes all registered options and discards the data from the command line and configuration files.
Any subparsers added using the add_cli_subparsers() will also be removed as a side-effect of this method.
- clear_default(name, group=None)
- Clear an override an opt's default value.
Clear a previously set override of the default value of given option.
- Parameters
- name -- the name/dest of the opt
- group -- an option OptGroup object or group name
- Raises
- NoSuchOptError, NoSuchGroupError
- clear_override(name, group=None)
- Clear an override an opt value.
Clear a previously set override of the command line, config file and default values of a given option.
- Parameters
- name -- the name/dest of the opt
- group -- an option OptGroup object or group name
- Raises
- NoSuchOptError, NoSuchGroupError
- property config_dirs
- disallow_names = ('project', 'prog', 'version', 'usage', 'default_config_files', 'default_config_dirs')
- find_file(name)
- Locate a file located alongside the config files.
Search for a file with the supplied basename in the directories which we have already loaded config files from and other known configuration directories.
The directory, if any, supplied by the config_dir option is searched first. Then the config_file option is iterated over and each of the base directories of the config_files values are searched. Failing both of these, the standard directories searched by the module level find_config_files() function is used. The first matching file is returned.
- Parameters
- name -- the filename, for example 'policy.json'
- Returns
- the path to a matching file, or None
- get_location(name, group=None)
- Return the location where the option is being set.
- Parameters
- name (str) -- The name of the option.
- group (str) -- The name of the group of the option. Defaults to 'DEFAULT'.
- Returns
- LocationInfo
SEE ALSO:
Added in version 5.3.0.
- import_group(group, module_str)
- Import an option group from a module.
Import a module and check that a given option group is registered.
This is intended for use with global configuration objects like cfg.CONF where modules commonly register options with CONF at module load time. If one module requires an option group defined by another module it can use this method to explicitly declare the dependency.
- Parameters
- group -- an option OptGroup object or group name
- module_str -- the name of a module to import
- Raises
- ImportError, NoSuchGroupError
- import_opt(name, module_str, group=None)
- Import an option definition from a module.
Import a module and check that a given option is registered.
This is intended for use with global configuration objects like cfg.CONF where modules commonly register options with CONF at module load time. If one module requires an option defined by another module it can use this method to explicitly declare the dependency.
- Parameters
- name -- the name/dest of the opt
- module_str -- the name of a module to import
- group -- an option OptGroup object or group name
- Raises
- NoSuchOptError, NoSuchGroupError
- list_all_sections()
- List all sections from the configuration.
Returns a sorted list of all section names found in the configuration files, whether declared beforehand or not.
- log_opt_values(logger, lvl)
- Log the value of all registered opts.
It's often useful for an app to log its configuration to a log file at startup for debugging. This method dumps to the entire config state to the supplied logger at a given log level.
- Parameters
- logger -- a logging.Logger object
- lvl -- the log level (for example logging.DEBUG) arg to logger.log()
- mutate_config_files()
- Reload configure files and parse all options.
Only options marked as 'mutable' will appear to change.
Hooks are called in a NON-DETERMINISTIC ORDER. Do not expect hooks to be called in the same order as they were added.
- Returns
- {(None or 'group', 'optname'): (old_value, new_value), ... }
- Raises
- Error if reloading fails
- print_help(file=None)
- Print the help message for the current program.
This method is for use after all CLI options are known registered using __call__() method. If this method is called before the __call__() is invoked, it throws NotInitializedError
- Parameters
- file -- the File object (if None, output is on sys.stdout)
- Raises
- NotInitializedError
- print_usage(file=None)
- Print the usage message for the current program.
This method is for use after all CLI options are known registered using __call__() method. If this method is called before the __call__() is invoked, it throws NotInitializedError
- Parameters
- file -- the File object (if None, output is on sys.stdout)
- Raises
- NotInitializedError
- register_cli_opt(opt, group=None)
- Register a CLI option schema.
CLI option schemas must be registered before the command line and config files are parsed. This is to ensure that all CLI options are shown in --help and option validation works as expected.
- Parameters
- opt -- an instance of an Opt sub-class
- group -- an optional OptGroup object or group name
- Returns
- False if the opt was already registered, True otherwise
- Raises
- DuplicateOptError, ArgsAlreadyParsedError
- register_cli_opts(opts, group=None)
- Register multiple CLI option schemas at once.
- register_group(group)
- Register an option group.
An option group must be registered before options can be registered with the group.
- Parameters
- group -- an OptGroup object
- register_mutate_hook(hook)
- Registers a hook to be called by mutate_config_files.
- Parameters
- hook -- a function accepting this ConfigOpts object and a dict of config mutations, as returned by mutate_config_files.
- Returns
- None
- register_opt(opt, group=None, cli=False)
- Register an option schema.
Registering an option schema makes any option value which is previously or subsequently parsed from the command line or config files available as an attribute of this object.
- Parameters
- opt -- an instance of an Opt sub-class
- group -- an optional OptGroup object or group name
- cli -- whether this is a CLI option
- Returns
- False if the opt was already registered, True otherwise
- Raises
- DuplicateOptError
- register_opts(opts, group=None)
- Register multiple option schemas at once.
- reload_config_files()
- Reload configure files and parse all options
- Returns
- False if reload configure files failed or else return True
- reset()
- Clear the object state and unset overrides and defaults.
- set_default(name, default, group=None)
- Override an opt's default value.
Override the default value of given option. A command line or config file value will still take precedence over this default.
- Parameters
- name -- the name/dest of the opt
- default -- the default value
- group -- an option OptGroup object or group name
- Raises
- NoSuchOptError, NoSuchGroupError
- set_override(name, override, group=None)
- Override an opt value.
Override the command line, config file and default values of a given option.
- Parameters
- name -- the name/dest of the opt
- override -- the override value
- group -- an option OptGroup object or group name
- Raises
- NoSuchOptError, NoSuchGroupError
- supported_shell_completion = ['bash', 'zsh']
- unregister_opt(opt, group=None)
- Unregister an option.
- Parameters
- opt -- an Opt object
- group -- an optional OptGroup object or group name
- Raises
- ArgsAlreadyParsedError, NoSuchGroupError
- unregister_opts(opts, group=None)
- Unregister multiple CLI option schemas at once.
- class oslo_config.cfg.ConfigParser(filename, sections)
- Bases: BaseParser
Parses a single config file, populating 'sections' to look like:
{'DEFAULT': {'key': [value, ...], ...},
...}
Also populates self._normalized which looks the same but with normalized section names.
- assignment(key, value)
- Called when a full assignment is parsed.
- error_no_section()
- new_section(section)
- Called when a new section is started.
- parse()
- parse_exc(msg, lineno, line=None)
- Common base class for all non-exit exceptions.
- exception oslo_config.cfg.ConfigSourceValueError(msg=None)
- Bases: Error, ValueError
Raised if a config source value does not match its opt type.
- exception oslo_config.cfg.DefaultValueError(msg=None)
- Bases: Error, ValueError
Raised if a default config type does not fit the opt type.
- class oslo_config.cfg.DeprecatedOpt(name, group=None)
- Bases: object
Represents a Deprecated option.
Here's how you can use it:
oldopts = [cfg.DeprecatedOpt('oldopt1', group='group1'),
cfg.DeprecatedOpt('oldopt2', group='group2')]
cfg.CONF.register_group(cfg.OptGroup('group1'))
cfg.CONF.register_opt(cfg.StrOpt('newopt', deprecated_opts=oldopts),
group='group1')
For options which have a single value (like in the example above), if the new option is present ("[group1]/newopt" above), it will override any deprecated options present ("[group1]/oldopt1" and "[group2]/oldopt2" above).
If no group is specified for a DeprecatedOpt option (i.e. the group is None), lookup will happen within the same group the new option is in. For example, if no group was specified for the second option 'oldopt2' in oldopts list:
oldopts = [cfg.DeprecatedOpt('oldopt1', group='group1'),
cfg.DeprecatedOpt('oldopt2')]
cfg.CONF.register_group(cfg.OptGroup('group1'))
cfg.CONF.register_opt(cfg.StrOpt('newopt', deprecated_opts=oldopts),
group='group1')
then lookup for that option will happen in group 'group1'.
If the new option is not present and multiple deprecated options are present, the option corresponding to the first element of deprecated_opts will be chosen.
Multi-value options will return all new and deprecated options. So if we have a multi-value option "[group1]/opt1" whose deprecated option is "[group2]/opt2", and the conf file has both these options specified like so:
[group1] opt1=val10,val11 [group2] opt2=val21,val22
Then the value of "[group1]/opt1" will be ['val10', 'val11', 'val21', 'val22'].
Added in version 1.2.
- class oslo_config.cfg.DictOpt(name, **kwargs)
- Bases: Opt
Option with Dict(String) type
Option with type oslo_config.types.Dict
- Parameters
- name -- the option's name
- **kwargs -- arbitrary keyword arguments passed to Opt
Added in version 1.2.
- exception oslo_config.cfg.DuplicateOptError(opt_name)
- Bases: Error
Raised if multiple opts with the same name are registered.
- exception oslo_config.cfg.Error(msg=None)
- Bases: Exception
Base class for cfg exceptions.
- class oslo_config.cfg.FloatOpt(name, min=None, max=None, **kwargs)
- Bases: Opt
Option with Float type
Option with type oslo_config.types.Float
- Parameters
- name -- the option's name
- min -- minimum value the float can take
- max -- maximum value the float can take
- **kwargs -- arbitrary keyword arguments passed to Opt
Changed in version 3.14: Added min and max parameters.
- class oslo_config.cfg.HostAddressOpt(name, version=None, **kwargs)
- Bases: Opt
Option for either an IP or a hostname.
Accepts valid hostnames and valid IP addresses.
Option with type oslo_config.types.HostAddress
- Parameters
- name -- the option's name
- version -- one of either 4, 6, or None to specify either version.
- **kwargs -- arbitrary keyword arguments passed to Opt
Added in version 3.22.
- class oslo_config.cfg.HostDomainOpt(name, version=None, **kwargs)
- Bases: Opt
Option for either an IP or a hostname.
Like HostAddress with the support of _ character.
Option with type oslo_config.types.HostDomain
- Parameters
- name -- the option's name
- version -- one of either 4, 6, or None to specify either version.
- **kwargs -- arbitrary keyword arguments passed to Opt
Added in version 8.6.
- class oslo_config.cfg.HostnameOpt(name, **kwargs)
- Bases: Opt
Option for a hostname. Only accepts valid hostnames.
Option with type oslo_config.types.Hostname
- Parameters
- name -- the option's name
- **kwargs -- arbitrary keyword arguments passed to Opt
Added in version 3.8.
- class oslo_config.cfg.IPOpt(name, version=None, **kwargs)
- Bases: Opt
Opt with IPAddress type
Option with type oslo_config.types.IPAddress
- Parameters
- name -- the option's name
- version -- one of either 4, 6, or None to specify either version.
- **kwargs -- arbitrary keyword arguments passed to Opt
Added in version 1.4.
- class oslo_config.cfg.IntOpt(name, min=None, max=None, choices=None, **kwargs)
- Bases: Opt
Option with Integer type
Option with type oslo_config.types.Integer
- Parameters
- name -- the option's name
- min -- minimum value the integer can take
- max -- maximum value the integer can take
- choices -- Optional sequence of either valid values or tuples of valid values with descriptions.
- **kwargs -- arbitrary keyword arguments passed to Opt
Changed in version 1.15: Added min and max parameters.
Changed in version 9.3.0: Added choices parameter.
- class oslo_config.cfg.ListOpt(name, item_type=None, bounds=None, **kwargs)
- Bases: Opt
Option with List(String) type
Option with type oslo_config.types.List
- Parameters
- name -- the option's name
- item_type -- type of items (see oslo_config.types)
- bounds -- if True the value should be inside "[" and "]" pair
- **kwargs -- arbitrary keyword arguments passed to Opt
Changed in version 2.5: Added item_type and bounds parameters.
- class oslo_config.cfg.LocationInfo(location, detail)
- Bases: tuple
- detail
- Alias for field number 1
- location
- Alias for field number 0
- class oslo_config.cfg.Locations(value, names=<not given>, *values, module=None, qualname=None, type=None, start=1, boundary=None)
- Bases: Enum
- command_line = (5, True)
- environment = (6, True)
- opt_default = (1, False)
- set_default = (2, False)
- set_override = (3, False)
- user = (4, True)
- class oslo_config.cfg.MultiOpt(name, item_type, **kwargs)
- Bases: Opt
Multi-value option.
Multi opt values are typed opts which may be specified multiple times. The opt value is a list containing all the values specified.
- Parameters
- name -- the option's name
- item_type -- Type of items (see oslo_config.types)
- **kwargs -- arbitrary keyword arguments passed to Opt
For example:
cfg.MultiOpt('foo',
item_type=types.Integer(),
default=None,
help="Multiple foo option")
The command line --foo=1 --foo=2 would result in cfg.CONF.foo containing [1,2]
Added in version 1.3.
- multi = True
- class oslo_config.cfg.MultiStrOpt(name, **kwargs)
- Bases: MultiOpt
MultiOpt with a MultiString item_type.
MultiOpt with a default oslo_config.types.MultiString item type.
- Parameters
- name -- the option's name
- **kwargs -- arbitrary keyword arguments passed to MultiOpt
- exception oslo_config.cfg.NoSuchGroupError(group_name)
- Bases: Error
Raised if a group which doesn't exist is referenced.
- exception oslo_config.cfg.NoSuchOptError(opt_name, group=None)
- Bases: Error, AttributeError
Raised if an opt which doesn't exist is referenced.
- exception oslo_config.cfg.NotInitializedError(msg=None)
- Bases: Error
Raised if parser is not initialized yet.
- class oslo_config.cfg.Opt(name, type=None, dest=None, short=None, default=None, positional=False, metavar=None, help=None, secret=False, required=None, deprecated_name=None, deprecated_group=None, deprecated_opts=None, sample_default=None, deprecated_for_removal=False, deprecated_reason=None, deprecated_since=None, mutable=False, advanced=False)
- Bases: object
Base class for all configuration options.
The only required parameter is the option's name. However, it is common to also supply a default and help string for all options.
- Parameters
- name -- the option's name
- type -- the option's type. Must be a callable object that takes string and returns converted and validated value
- dest -- the name of the corresponding ConfigOpts property
- short -- a single character CLI option name
- default -- the default value of the option
- positional -- True if the option is a positional CLI argument
- metavar -- the option argument to show in --help
- help -- an explanation of how the option is used
- secret -- true if the value should be obfuscated in log output
- required -- true if a value must be supplied for this option
- deprecated_name -- deprecated name option. Acts like an alias
- deprecated_group -- the group containing a deprecated alias
- deprecated_opts -- list of DeprecatedOpt
- sample_default -- a default string for sample config files
- deprecated_for_removal -- indicates whether this opt is planned for removal in a future release
- deprecated_reason -- indicates why this opt is planned for removal in a future release. Silently ignored if deprecated_for_removal is False
- deprecated_since -- indicates which release this opt was deprecated in. Accepts any string, though valid version strings are encouraged. Silently ignored if deprecated_for_removal is False
- mutable -- True if this option may be reloaded
- advanced -- a bool True/False value if this option has advanced usage and is not normally used by the majority of users
An Opt object has no public methods, but has a number of public properties:
- name
- the name of the option, which may include hyphens
- type
- a callable object that takes string and returns converted and validated value. Default types are available from oslo_config.types
- dest
- the (hyphen-less) ConfigOpts property which contains the option value
- short
- a single character CLI option name
- default
- the default value of the option
- sample_default
- a sample default value string to include in sample config files
- positional
- True if the option is a positional CLI argument
- metavar
- the name shown as the argument to a CLI option in --help output
- help
- a string explaining how the option's value is used
- advanced
- in sample files, a bool value indicating the option is advanced
Changed in version 1.2: Added deprecated_opts parameter.
Changed in version 1.4: Added sample_default parameter.
Changed in version 1.9: Added deprecated_for_removal parameter.
Changed in version 2.7: An exception is now raised if the default value has the wrong type.
Changed in version 3.2: Added deprecated_reason parameter.
Changed in version 3.5: Added mutable parameter.
Changed in version 3.12: Added deprecated_since parameter.
Changed in version 3.15: Added advanced parameter and attribute.
- multi = False
- class oslo_config.cfg.OptGroup(name, title=None, help=None, dynamic_group_owner='', driver_option='')
- Bases: object
Represents a group of opts.
CLI opts in the group are automatically prefixed with the group name.
Each group corresponds to a section in config files.
An OptGroup object has no public methods, but has a number of public string properties:
- name
- the name of the group
- title
- the group title as displayed in --help
- help
- the group description as displayed in --help
- Parameters
- name (str) -- the group name
- title (str) -- the group title for --help
- help (str) -- the group description for --help
- dynamic_group_owner (str) -- The name of the option that controls repeated instances of this group.
- driver_option (str) -- The name of the option within the group that controls which driver will register options.
- exception oslo_config.cfg.ParseError(msg, lineno, line, filename)
- Bases: ParseError
- class oslo_config.cfg.PortOpt(name, min=None, max=None, choices=None, **kwargs)
- Bases: Opt
Option for a TCP/IP port number. Ports can range from 0 to 65535.
Option with type oslo_config.types.Integer
- Parameters
- name -- the option's name
- min -- minimum value the port can take
- max -- maximum value the port can take
- choices -- Optional sequence of either valid values or tuples of valid values with descriptions.
- **kwargs -- arbitrary keyword arguments passed to Opt
Added in version 2.6.
Changed in version 3.2: Added choices parameter.
Changed in version 3.4: Allow port number with 0.
Changed in version 3.16: Added min and max parameters.
Changed in version 5.2: The choices parameter will now accept a sequence of tuples, where each tuple is of form (choice, description)
- exception oslo_config.cfg.RequiredOptError(opt_name, group=None)
- Bases: Error
Raised if an option is required but no value is supplied by the user.
- class oslo_config.cfg.StrOpt(name, choices=None, quotes=None, regex=None, ignore_case=False, max_length=None, **kwargs)
- Bases: Opt
Option with String type
Option with type oslo_config.types.String
- Parameters
- name -- the option's name
- choices -- Optional sequence of either valid values or tuples of valid values with descriptions.
- quotes -- If True and string is enclosed with single or double quotes, will strip those quotes.
- regex -- Optional regular expression (string or compiled regex) that the value must match on an unanchored search.
- ignore_case -- If True case differences (uppercase vs. lowercase) between 'choices' or 'regex' will be ignored.
- max_length -- If positive integer, the value must be less than or equal to this parameter.
- **kwargs -- arbitrary keyword arguments passed to Opt
Changed in version 2.7: Added quotes parameter
Changed in version 2.7: Added regex parameter
Changed in version 2.7: Added ignore_case parameter
Changed in version 2.7: Added max_length parameter
Changed in version 5.2: The choices parameter will now accept a sequence of tuples, where each tuple is of form (choice, description)
- class oslo_config.cfg.SubCommandOpt(name, dest=None, handler=None, title=None, description=None, help=None)
- Bases: Opt
Sub-command options.
Sub-command options allow argparse sub-parsers to be used to parse additional command line arguments.
The handler argument to the SubCommandOpt constructor is a callable which is supplied an argparse subparsers object. Use this handler callable to add sub-parsers.
The opt value is SubCommandAttr object with the name of the chosen sub-parser stored in the 'name' attribute and the values of other sub-parser arguments available as additional attributes.
- Parameters
- name -- the option's name
- dest -- the name of the corresponding ConfigOpts property
- handler -- callable which is supplied subparsers object when invoked
- title -- title of the sub-commands group in help output
- description -- description of the group in help output
- help -- a help string giving an overview of available sub-commands
- exception oslo_config.cfg.TemplateSubstitutionError(msg=None)
- Bases: Error
Raised if an error occurs substituting a variable in an opt value.
- class oslo_config.cfg.URIOpt(name, max_length=None, schemes=None, **kwargs)
- Bases: Opt
Opt with URI type
Option with type oslo_config.types.URI
- Parameters
- name -- the option's name
- max_length -- If positive integer, the value must be less than or equal to this parameter.
- schemes -- list of valid URI schemes, e.g. 'https', 'ftp', 'git'
- **kwargs -- arbitrary keyword arguments passed to Opt
Added in version 3.12.
Changed in version 3.14: Added max_length parameter
Changed in version 3.18: Added schemes parameter
- oslo_config.cfg.find_config_dirs(project=None, prog=None, extension='.conf.d')
- Return a list of default configuration dirs.
- Parameters
- project -- an optional project name
- prog -- the program name, defaulting to the basename of sys.argv[0], without extension .py
- extension -- the type of the config directory. Defaults to '.conf.d'
We default to two config dirs: [${project}.conf.d/, ${prog}.conf.d/]. If no project name is supplied, we only look for ${prog.conf.d/}.
And we look for those config dirs in the following directories:
~/.${project}/
~/
/etc/${project}/
/etc/
${SNAP_COMMON}/etc/${project}
${SNAP}/etc/${project}
We return an absolute path for each of the two config dirs, in the first place we find it (iff we find it).
For example, if project=foo, prog=bar and /etc/foo/foo.conf.d/, /etc/bar.conf.d/ and ~/.foo/bar.conf.d/ all exist, then we return ['/etc/foo/foo.conf.d/', '~/.foo/bar.conf.d/']
- oslo_config.cfg.find_config_files(project=None, prog=None, extension='.conf')
- Return a list of default configuration files.
- Parameters
- project -- an optional project name
- prog -- the program name, defaulting to the basename of sys.argv[0], without extension .py
- extension -- the type of the config file
We default to two config files: [${project}.conf, ${prog}.conf]
And we look for those config files in the following directories:
~/.${project}/
~/
/etc/${project}/
/etc/
${SNAP_COMMON}/etc/${project}
${SNAP}/etc/${project}
We return an absolute path for (at most) one of each the default config files, for the topmost directory it exists in.
For example, if project=foo, prog=bar and /etc/foo/foo.conf, /etc/bar.conf and ~/.foo/bar.conf all exist, then we return ['/etc/foo/foo.conf', '~/.foo/bar.conf']
If no project name is supplied, we only look for ${prog}.conf.
- oslo_config.cfg.set_defaults(opts, **kwargs)
oslo_config.fixture module
- class oslo_config.fixture.Config(conf=<oslo_config.cfg.ConfigOpts object>)
- Bases: Fixture
Allows overriding configuration settings for the test.
conf will be reset on cleanup.
- config(**kw)
- Override configuration values.
The keyword arguments are the names of configuration options to override and their values.
If a group argument is supplied, the overrides are applied to the specified configuration option group, otherwise the overrides are applied to the default group.
- load_raw_values(group=None, **kwargs)
- Load raw values into the configuration without registering them.
This method adds a series of parameters into the current config instance, as if they had been loaded by a ConfigParser. This method does not require that you register the configuration options first, however the values loaded will not be accessible until you do.
- register_cli_opt(opt, group=None)
- Register a single CLI option for the test run.
Options registered in this manner will automatically be unregistered during cleanup.
If a group argument is supplied, it will register the new option to that group, otherwise the option is registered to the default group.
CLI options must be registered before the command line and config files are parsed. This is to ensure that all CLI options are shown in --help and option validation works as expected.
- register_cli_opts(opts, group=None)
- Register multiple CLI options for the test run.
This works in the same manner as register_opt() but takes a list of options as the first argument. All arguments will be registered to the same group if the group argument is supplied, otherwise all options will be registered to the default group.
CLI options must be registered before the command line and config files are parsed. This is to ensure that all CLI options are shown in --help and option validation works as expected.
- register_opt(opt, group=None)
- Register a single option for the test run.
Options registered in this manner will automatically be unregistered during cleanup.
If a group argument is supplied, it will register the new option to that group, otherwise the option is registered to the default group.
- register_opts(opts, group=None)
- Register multiple options for the test run.
This works in the same manner as register_opt() but takes a list of options as the first argument. All arguments will be registered to the same group if the group argument is supplied, otherwise all options will be registered to the default group.
- setUp()
- Prepare the Fixture for use.
This should not be overridden. Concrete fixtures should implement _setUp. Overriding of setUp is still supported, just not recommended.
After setUp has completed, the fixture will have one or more attributes which can be used (these depend totally on the concrete subclass).
- Raises
- MultipleExceptions if _setUp fails. The last exception captured within the MultipleExceptions will be a SetupError exception.
- Returns
- None.
- Changed in 1.3
- The recommendation to override setUp has been reversed - before 1.3, setUp() should be overridden, now it should not be.
- Changed in 1.3.1
- BaseException is now caught, and only subclasses of Exception are wrapped in MultipleExceptions.
- set_config_dirs(config_dirs)
- Specify a list of config dirs to read.
This method allows you to predefine the list of configuration dirs that are loaded by oslo_config. It will ensure that your tests do not attempt to autodetect, and accidentally pick up config files from locally installed services.
- set_config_files(config_files)
- Specify a list of config files to read.
This method allows you to predefine the list of configuration files that are loaded by oslo_config. It will ensure that your tests do not attempt to autodetect, and accidentally pick up config files from locally installed services.
- set_default(name, default, group=None)
- Set a default value for an option.
This method is not necessarily meant to be invoked directly. It is here to allow the set_defaults() functions in various Oslo libraries to work with a Config fixture instead of a ConfigOpts instance.
Use it like:
class MyTest(testtools.TestCase):
def setUp(self):
super(MyTest, self).setUp()
self.conf = self.useFixture(fixture.Config())
def test_something(self):
some_library.set_defaults(self.conf, name='value')
some_library.do_something_exciting()
oslo_config.generator module
Sample configuration generator
Tool for generating a sample configuration file. See ../doc/source/cli/generator.rst for details.
Added in version 1.4.
- oslo_config.generator.generate(conf, output_file=None)
- Generate a sample config file.
List all of the options available via the namespaces specified in the given configuration and write a description of them to the specified output file.
- Parameters
- conf -- a ConfigOpts instance containing the generator's configuration
- oslo_config.generator.i18n_representer(dumper, data)
- oslo_i18n yaml representer
Returns a translated to the default locale string for yaml.safe_dump
- Parameters
- dumper -- a SafeDumper instance passed by yaml.safe_dump
- data -- a oslo_i18n._message.Message instance
- oslo_config.generator.main(args=None)
- The main function of oslo-config-generator.
- oslo_config.generator.on_load_failure_callback(*args, **kwargs)
- oslo_config.generator.register_cli_opts(conf)
- Register the formatter's CLI options with a ConfigOpts instance.
Note, this must be done before the ConfigOpts instance is called to parse the configuration.
- Parameters
- conf -- a ConfigOpts instance
- Raises
- DuplicateOptError, ArgsAlreadyParsedError
oslo_config.iniparser module
- class oslo_config.iniparser.BaseParser
- Bases: object
- assignment(key, value)
- Called when a full assignment is parsed.
- comment(comment)
- Called when a comment is parsed.
- error_empty_key(line)
- error_invalid_assignment(line)
- error_no_section_end_bracket(line)
- error_no_section_name(line)
- error_unexpected_continuation(line)
- lineno = 0
- new_section(section)
- Called when a new section is started.
- parse(lineiter)
- parse_exc
- alias of ParseError
- exception oslo_config.iniparser.ParseError(message, lineno, line)
- Bases: Exception
oslo_config.sphinxconfiggen module
- oslo_config.sphinxconfiggen.generate_sample(app)
- oslo_config.sphinxconfiggen.setup(app)
oslo_config.sphinxext module
- class oslo_config.sphinxext.ConfigDomain(env: BuildEnvironment)
- Bases: Domain
oslo.config domain.
- directives: dict[str, type[Directive]] = {'group': <class 'oslo_config.sphinxext.ConfigGroup'>, 'option': <class 'oslo_config.sphinxext.ConfigOption'>}
- directive name -> directive class
- initial_data: dict = {'groups': {}, 'options': {}}
- data value for a fresh environment
- label = 'oslo.config'
- domain label: longer, more descriptive (used in messages)
- merge_domaindata(docnames, otherdata)
- Merge in data regarding docnames from a different domaindata inventory (coming from a subprocess in parallel builds).
- name = 'oslo.config'
- domain name: should be short, but unique
- object_types: dict[str, ObjType] = {'configoption': <sphinx.domains.ObjType object>}
- type (usually directive) name -> ObjType instance
- resolve_xref(env, fromdocname, builder, typ, target, node, contnode)
- Resolve cross-references
- roles: dict[str, RoleFunction | XRefRole] = {'group': <oslo_config.sphinxext.ConfigGroupXRefRole object>, 'option': <oslo_config.sphinxext.ConfigOptXRefRole object>}
- role name -> role callable
- class oslo_config.sphinxext.ConfigGroup(name, arguments, options, content, lineno, content_offset, block_text, state, state_machine)
- Bases: Directive
- has_content = True
- May the directive have content?
- option_spec = {'namespace': <function unchanged>}
- Mapping of option names to validator functions.
- optional_arguments = 0
- Number of optional arguments after the required arguments.
- required_arguments = 1
- Number of required directive arguments.
- run()
- class oslo_config.sphinxext.ConfigGroupXRefRole
- Bases: XRefRole
Handles :oslo.config:group: roles pointing to configuration groups.
- process_link(env, refnode, has_explicit_title, title, target)
- Called after parsing title and target text, and creating the reference node (given in refnode). This method can alter the reference node and must return a new (or the same) (title, target) tuple.
- class oslo_config.sphinxext.ConfigOptXRefRole
- Bases: XRefRole
Handles :oslo.config:option: roles pointing to configuration options.
- process_link(env, refnode, has_explicit_title, title, target)
- Called after parsing title and target text, and creating the reference node (given in refnode). This method can alter the reference node and must return a new (or the same) (title, target) tuple.
- class oslo_config.sphinxext.ConfigOption(name, arguments, options, content, lineno, content_offset, block_text, state, state_machine)
- Bases: ObjectDescription
Description of a configuration option (.. option).
- add_target_and_index(firstname, sig, signode)
- Add cross-reference IDs and entries to self.indexnode, if applicable.
name is whatever handle_signature() returned.
- handle_signature(sig, signode)
- Transform an option description into RST nodes.
- class oslo_config.sphinxext.ShowOptionsDirective(name, arguments, options, content, lineno, content_offset, block_text, state, state_machine)
- Bases: Directive
- has_content = True
- May the directive have content?
- option_spec = {'config-file': <function unchanged>, 'split-namespaces': <function flag>}
- Mapping of option names to validator functions.
- run()
- oslo_config.sphinxext.setup(app)
oslo_config.types module
Type conversion and validation classes for configuration options.
Use these classes as values for the type argument to oslo_config.cfg.Opt and its subclasses.
Added in version 1.3.
- class oslo_config.types.Boolean(type_name='boolean value')
- Bases: ConfigType
Boolean type.
Values are case insensitive and can be set using 1/0, yes/no, true/false or on/off.
- Parameters
- type_name -- Type name to be used in the sample config file.
Changed in version 2.7: Added type_name parameter.
- FALSE_VALUES = ['false', '0', 'off', 'no']
- TRUE_VALUES = ['true', '1', 'on', 'yes']
- class oslo_config.types.ConfigType(type_name='unknown type')
- Bases: object
- NONE_DEFAULT = '<None>'
- format_defaults(default, sample_default=None)
- Return a list of formatted default values.
- quote_trailing_and_leading_space(str_val)
- class oslo_config.types.Dict(value_type=None, bounds=False, type_name='dict value', key_value_separator=':')
- Bases: ConfigType
Dictionary type.
Dictionary type values are key:value pairs separated by commas. The resulting value is a dictionary of these key/value pairs. Type of dictionary key is always string, but dictionary value type can be customized.
- Parameters
- value_type -- type of values in dictionary
- bounds -- if True, value should be inside "{" and "}" pair
- type_name -- Type name to be used in the sample config file.
Changed in version 2.7: Added type_name parameter.
Changed in version 9.5: Added key_value_separator parameter.
- class oslo_config.types.Float(min=None, max=None, type_name='floating point value')
- Bases: Number
Float type.
- Parameters
- min -- Optional check that value is greater than or equal to min.
- max -- Optional check that value is less than or equal to max.
- type_name -- Type name to be used in the sample config file.
Changed in version 2.7: Added type_name parameter.
Changed in version 3.14: Added min and max parameters. If choices are also supplied, they must be within the range.
- class oslo_config.types.HostAddress(version=None, type_name='host address value')
- Bases: ConfigType
Host Address type.
Represents both valid IP addresses and valid host domain names including fully qualified domain names. Performs strict checks for both IP addresses and valid hostnames, matching the opt values to the respective types as per RFC1912.
- Parameters
- version -- defines which version should be explicitly checked (4 or 6) in case of an IP address
- type_name -- Type name to be used in the sample config file.
- class oslo_config.types.HostDomain(version=None, type_name='host domain value')
- Bases: HostAddress
Host Domain type.
Like HostAddress with the support of _ character.
- Parameters
- version -- defines which version should be explicitly checked (4 or 6) in case of an IP address
- type_name -- Type name to be used in the sample config file.
- DOMAIN_REGEX = '(?!-)[A-Z0-9-_]{1,63}(?<!-)$'
- class oslo_config.types.Hostname(type_name='hostname value')
- Bases: ConfigType
Host domain name type.
A hostname refers to a valid DNS or hostname. It must not be longer than 253 characters, have a segment greater than 63 characters, nor start or end with a hyphen.
- Parameters
- type_name -- Type name to be used in the sample config file.
- HOSTNAME_REGEX = '(?!-)[A-Z0-9-]{1,63}(?<!-)$'
- class oslo_config.types.IPAddress(version=None, type_name='IP address value')
- Bases: ConfigType
IP address type
Represents either ipv4 or ipv6. Without specifying version parameter both versions are checked
- Parameters
- version -- defines which version should be explicitly checked (4 or 6)
- type_name -- Type name to be used in the sample config file.
Changed in version 2.7: Added type_name parameter.
- class oslo_config.types.Integer(min=None, max=None, type_name='integer value', choices=None)
- Bases: Number
Integer type.
Converts value to an integer optionally doing range checking. If value is whitespace or empty string will return None.
- Parameters
- min -- Optional check that value is greater than or equal to min.
- max -- Optional check that value is less than or equal to max.
- type_name -- Type name to be used in the sample config file.
- choices -- Optional sequence of either valid values or tuples of valid values with descriptions.
Changed in version 2.4: The class now honors zero for min and max parameters.
Changed in version 2.7: Added type_name parameter.
Changed in version 3.2: Added choices parameter.
Changed in version 3.16: choices is no longer mutually exclusive with min/max. If those are supplied, all choices are verified to be within the range.
Changed in version 5.2: The choices parameter will now accept a sequence of tuples, where each tuple is of form (choice, description)
- class oslo_config.types.List(item_type=None, bounds=False, type_name='list value')
- Bases: ConfigType
List type.
Represent values of other (item) type, separated by commas. The resulting value is a list containing those values.
List doesn't know if item type can also contain commas. To workaround this it tries the following: if the next part fails item validation, it appends comma and next item until validation succeeds or there is no parts left. In the later case it will signal validation error.
- Parameters
- item_type -- Type of list items. Should be an instance of ConfigType.
- bounds -- if True, value should be inside "[" and "]" pair
- type_name -- Type name to be used in the sample config file.
Changed in version 2.7: Added type_name parameter.
- class oslo_config.types.MultiString(type_name='multi valued')
- Bases: String
Multi-valued string.
- NONE_DEFAULT = ['']
- format_defaults(default, sample_default=None)
- Return a list of formatted default values.
- class oslo_config.types.Number(num_type, type_name, min=None, max=None, choices=None)
- Bases: ConfigType
Number class, base for Integer and Float.
- Parameters
- num_type -- the type of number used for casting (i.e int, float)
- type_name -- Type name to be used in the sample config file.
- min -- Optional check that value is greater than or equal to min.
- max -- Optional check that value is less than or equal to max.
- choices -- Optional sequence of either valid values or tuples of valid values with descriptions.
Added in version 3.14.
Changed in version 5.2: The choices parameter will now accept a sequence of tuples, where each tuple is of form (choice, description)
- class oslo_config.types.Port(min=None, max=None, type_name='port', choices=None)
- Bases: Integer
Port type
Represents a L4 Port.
- Parameters
- min -- Optional check that value is greater than or equal to min.
- max -- Optional check that value is less than or equal to max.
- type_name -- Type name to be used in the sample config file.
- choices -- Optional sequence of either valid values or tuples of valid values with descriptions.
Added in version 3.16.
Changed in version 5.2: The choices parameter will now accept a sequence of tuples, where each tuple is of form (choice, description)
- PORT_MAX = 65535
- PORT_MIN = 0
- class oslo_config.types.Range(min=None, max=None, inclusive=True, type_name='range value')
- Bases: ConfigType
Range type.
Represents a range of integers. A range is identified by an integer both sides of a '-' character. Negatives are allowed. A single number is also a valid range.
- Parameters
- min -- Optional check that lower bound is greater than or equal to min.
- max -- Optional check that upper bound is less than or equal to max.
- inclusive -- True if the right bound is to be included in the range.
- type_name -- Type name to be used in the sample config file.
Added in version 3.18.
- class oslo_config.types.String(choices=None, quotes=False, regex=None, ignore_case=False, max_length=None, type_name='string value')
- Bases: ConfigType
String type.
String values do not get transformed and are returned as str objects.
- Parameters
- choices -- Optional sequence of either valid values or tuples of valid values with descriptions. Mutually exclusive with 'regex'.
- quotes -- If True and string is enclosed with single or double quotes, will strip those quotes. Will signal error if string have quote at the beginning and no quote at the end. Turned off by default. Useful if used with container types like List.
- regex -- Optional regular expression (string or compiled regex) that the value must match on an unanchored search. Mutually exclusive with 'choices'.
- ignore_case -- If True case differences (uppercase vs. lowercase) between 'choices' or 'regex' will be ignored; defaults to False.
- max_length -- Optional integer. If a positive value is specified, a maximum length of an option value must be less than or equal to this parameter. Otherwise no length check will be done.
- type_name -- Type name to be used in the sample config file.
Changed in version 2.1: Added regex parameter.
Changed in version 2.5: Added ignore_case parameter.
Changed in version 2.7: Added max_length parameter. Added type_name parameter.
Changed in version 5.2: The choices parameter will now accept a sequence of tuples, where each tuple is of form (choice, description)
- class oslo_config.types.URI(max_length=None, schemes=None, type_name='uri value')
- Bases: ConfigType
URI type
Represents URI. Value will be validated as RFC 3986.
- Parameters
- max_length -- Optional integer. If a positive value is specified, a maximum length of an option value must be less than or equal to this parameter. Otherwise no length check will be done.
- schemes -- List of valid schemes.
- type_name -- Type name to be used in the sample config file.
Changed in version 3.14: Added max_length parameter.
Changed in version 3.18: Added schemes parameter.
- value
oslo_config.validator module
Configuration Validator
Uses the sample config generator configuration file to retrieve a list of all the available options in a project, then compares it to what is configured in the provided file. If there are any options set that are not defined in the project then it returns those errors.
- oslo_config.validator.load_opt_data(conf)
- oslo_config.validator.main()
- The main function of oslo-config-validator.
oslo_config.version module
Module contents
Defining Options
Configuration options may be set on the command line, in the environment, or in config files. Options are processed in that order.
The schema for each option is defined using the Opt class or its sub-classes, for example:
from oslo_config import cfg from oslo_config import types PortType = types.Integer(1, 65535) common_opts = [
cfg.StrOpt('bind_host',
default='0.0.0.0',
help='IP address to listen on.'),
cfg.Opt('bind_port',
type=PortType,
default=9292,
help='Port number to listen on.') ]
Option Types
Options can have arbitrary types via the type parameter to the Opt constructor. The type parameter is a callable object that takes a string and either returns a value of that particular type or raises ValueError if the value can not be converted.
For convenience, there are predefined option subclasses in oslo_config.cfg that set the option type as in the following table:
| Type | Option |
| oslo_config.types.String | oslo_config.cfg.StrOpt |
| oslo_config.types.String | oslo_config.cfg.SubCommandOpt |
| oslo_config.types.Boolean | oslo_config.cfg.BoolOpt |
| oslo_config.types.Integer | oslo_config.cfg.IntOpt |
| oslo_config.types.Float | oslo_config.cfg.FloatOpt |
| oslo_config.types.Port | oslo_config.cfg.PortOpt |
| oslo_config.types.List | oslo_config.cfg.ListOpt |
| oslo_config.types.Dict | oslo_config.cfg.DictOpt |
| oslo_config.types.IPAddress | oslo_config.cfg.IPOpt |
| oslo_config.types.Hostname | oslo_config.cfg.HostnameOpt |
| oslo_config.types.HostAddress | oslo_config.cfg.HostAddressOpt |
| oslo_config.types.URI | oslo_config.cfg.URIOpt |
For oslo_config.cfg.MultiOpt the item_type parameter defines the type of the values. For convenience, oslo_config.cfg.MultiStrOpt is MultiOpt with the item_type parameter set to oslo_config.types.MultiString.
The following example defines options using the convenience classes:
enabled_apis_opt = cfg.ListOpt('enabled_apis',
default=['ec2', 'osapi_compute'],
help='List of APIs to enable by default.')
DEFAULT_EXTENSIONS = [
'nova.api.openstack.compute.contrib.standard_extensions'
]
osapi_compute_extension_opt = cfg.MultiStrOpt('osapi_compute_extension',
default=DEFAULT_EXTENSIONS)
Registering Options
Option schemas are registered with the config manager at runtime, but before the option is referenced:
class ExtensionManager:
enabled_apis_opt = cfg.ListOpt(...)
def __init__(self, conf):
self.conf = conf
self.conf.register_opt(enabled_apis_opt)
...
def _load_extensions(self):
for ext_factory in self.conf.osapi_compute_extension:
....
A common usage pattern is for each option schema to be defined in the module or class which uses the option:
opts = ... def add_common_opts(conf):
conf.register_opts(opts) def get_bind_host(conf):
return conf.bind_host def get_bind_port(conf):
return conf.bind_port
An option may optionally be made available via the command line. Such options must be registered with the config manager before the command line is parsed (for the purposes of --help and CLI arg validation).
Note that options registered for CLI use do not need to be registered again for use from other config sources, such as files. CLI options can be read from either the CLI or from the other enabled config sources.
cli_opts = [
cfg.BoolOpt('verbose',
short='v',
default=False,
help='Print more verbose output.'),
cfg.BoolOpt('debug',
short='d',
default=False,
help='Print debugging output.'), ] def add_common_opts(conf):
conf.register_cli_opts(cli_opts)
Option Groups
Options can be registered as belonging to a group:
rabbit_group = cfg.OptGroup(name='rabbit',
title='RabbitMQ options') rabbit_host_opt = cfg.StrOpt('host',
default='localhost',
help='IP/hostname to listen on.'), rabbit_port_opt = cfg.PortOpt('port',
default=5672,
help='Port number to listen on.') def register_rabbit_opts(conf):
conf.register_group(rabbit_group)
# options can be registered under a group in either of these ways:
conf.register_opt(rabbit_host_opt, group=rabbit_group)
conf.register_opt(rabbit_port_opt, group='rabbit')
If no group attributes are required other than the group name, the group need not be explicitly registered for example:
def register_rabbit_opts(conf):
# The group will automatically be created, equivalent calling:
# conf.register_group(OptGroup(name='rabbit'))
conf.register_opt(rabbit_port_opt, group='rabbit')
If no group is specified, options belong to the 'DEFAULT' section of config files:
glance-api.conf:
[DEFAULT]
bind_port = 9292
...
[rabbit]
host = localhost
port = 5672
use_ssl = False
userid = guest
password = guest
virtual_host = /
Command-line options in a group are automatically prefixed with the group name:
--rabbit-host localhost --rabbit-port 9999
Dynamic Groups
Groups can be registered dynamically by application code. This introduces a challenge for the sample generator, discovery mechanisms, and validation tools, since they do not know in advance the names of all of the groups. The dynamic_group_owner parameter to the constructor specifies the full name of an option registered in another group that controls repeated instances of a dynamic group. This option is usually a MultiStrOpt.
For example, Cinder supports multiple storage backend devices and services. To configure Cinder to communicate with multiple backends, the enabled_backends option is set to the list of names of backends. Each backend group includes the options for communicating with that device or service.
Driver Groups
Groups can have dynamic sets of options, usually based on a driver that has unique requirements. This works at runtime because the code registers options before it uses them, but it introduces a challenge for the sample generator, discovery mechanisms, and validation tools because they do not know in advance the correct options for a group.
To address this issue, the driver option for a group can be named using the driver_option parameter. Each driver option should define its own discovery entry point namespace to return the set of options for that driver, named using the prefix "oslo.config.opts." followed by the driver option name.
In the Cinder case described above, a volume_backend_name option is part of the static definition of the group, so driver_option should be set to "volume_backend_name". And plugins should be registered under "oslo.config.opts.volume_backend_name" using the same names as the main plugin registered with "oslo.config.opts". The drivers residing within the Cinder code base have an entry point named "cinder" registered.
Special Handling Instructions
Options may be declared as required so that an error is raised if the user does not supply a value for the option:
opts = [
cfg.StrOpt('service_name', required=True),
cfg.StrOpt('image_id', required=True),
... ]
Options may be declared as secret so that their values are not leaked into log files:
opts = [
cfg.StrOpt('s3_store_access_key', secret=True),
cfg.StrOpt('s3_store_secret_key', secret=True),
... ]
Dictionary Options
If you need end users to specify a dictionary of key/value pairs, then you can use the DictOpt:
opts = [
cfg.DictOpt('foo',
default={}) ]
The end users can then specify the option foo in their configuration file as shown below:
[DEFAULT] foo = k1:v1,k2:v2
Advanced Option
Use if you need to label an option as advanced in sample files, indicating the option is not normally used by the majority of users and might have a significant effect on stability and/or performance:
from oslo_config import cfg opts = [
cfg.StrOpt('option1', default='default_value',
advanced=True, help='This is help '
'text.'),
cfg.PortOpt('option2', default='default_value',
help='This is help text.'), ] CONF = cfg.CONF CONF.register_opts(opts)
This will result in the option being pushed to the bottom of the namespace and labeled as advanced in the sample files, with a notation about possible effects:
[DEFAULT] ... # This is help text. (string value) # option2 = default_value ... <pushed to bottom of section> ... # This is help text. (string value) # Advanced Option: intended for advanced users and not used # by the majority of users, and might have a significant # effect on stability and/or performance. # option1 = default_value
Choosing group names for configuration options
Applications should use a meaningful name without a prefix. For Oslo libraries, when naming groups for configuration options using the name of the library itself instead of a descriptive name to help avoid collisions. If the library name is namespaced then use '_' as a separator in the group name.
For example, the oslo.log library should use oslo_log as the group name.
Accessing Option Values In Your Code
Option values in the default group are referenced as attributes/properties on the config manager; groups are also attributes on the config manager, with attributes for each of the options associated with the group:
server.start(app, conf.bind_port, conf.bind_host, conf) self.connection = kombu.connection.BrokerConnection(
hostname=conf.rabbit.host,
port=conf.rabbit.port,
...)
Loading Configuration Files
The config manager has two CLI options defined by default, --config-file and --config-dir:
class ConfigOpts:
def __call__(self, ...):
opts = [
MultiStrOpt('config-file',
...),
StrOpt('config-dir',
...),
]
self.register_cli_opts(opts)
Option values are parsed from any supplied config files using oslo_config.iniparser. If none are specified, a default set is used for example glance-api.conf and glance-common.conf:
glance-api.conf:
[DEFAULT]
bind_port = 9292 glance-common.conf:
[DEFAULT]
bind_host = 0.0.0.0
Lines in a configuration file should not start with whitespace. A configuration file also supports comments, which must start with '#' or ';'. Option values in config files and those on the command line are parsed in order. The same option (includes deprecated option name and current option name) can appear many times, in config files or on the command line. Later values always override earlier ones.
The order of configuration files inside the same configuration directory is defined by the alphabetic sorting order of their file names. Files in a configuration directory are parsed after any individual configuration files, so values that appear in both a configuration file and configuration directory will use the value from the directory.
The parsing of CLI args and config files is initiated by invoking the config manager for example:
conf = cfg.ConfigOpts()
conf.register_opt(cfg.BoolOpt('verbose', ...))
conf(sys.argv[1:])
if conf.verbose:
...
Option Value Interpolation
Option values may reference other values using PEP 292 string substitution:
opts = [
cfg.StrOpt('state_path',
default=os.path.join(os.path.dirname(__file__), '../'),
help='Top-level directory for maintaining nova state.'),
cfg.StrOpt('sqlite_db',
default='nova.sqlite',
help='File name for SQLite.'),
cfg.StrOpt('sql_connection',
default='sqlite:///$state_path/$sqlite_db',
help='Connection string for SQL database.'), ]
NOTE:
NOTE:
Command Line Options
Positional Command Line Arguments
Positional command line arguments are supported via a 'positional' Opt constructor argument:
>>> conf = cfg.ConfigOpts()
>>> conf.register_cli_opt(cfg.MultiStrOpt('bar', positional=True))
True
>>> conf(['a', 'b'])
>>> conf.bar
['a', 'b']
By default, positional arguments are also required. You may opt-out of this behavior by setting required=False, to have an optional positional argument.
Sub-Parsers
It is also possible to use argparse "sub-parsers" to parse additional command line arguments using the SubCommandOpt class:
>>> def add_parsers(subparsers):
... list_action = subparsers.add_parser('list')
... list_action.add_argument('id')
...
>>> conf = cfg.ConfigOpts()
>>> conf.register_cli_opt(cfg.SubCommandOpt('action', handler=add_parsers))
True
>>> conf(args=['list', '10'])
>>> conf.action.name, conf.action.id
('list', '10')
Option Deprecation
If you want to rename some options, move them to another group or remove completely, you may change their declarations using deprecated_name, deprecated_group and deprecated_for_removal parameters to the Opt constructor:
from oslo_config import cfg
conf = cfg.ConfigOpts()
opt_1 = cfg.StrOpt('opt_1', default='foo', deprecated_name='opt1')
opt_2 = cfg.StrOpt('opt_2', default='spam', deprecated_group='DEFAULT')
opt_3 = cfg.BoolOpt('opt_3', default=False, deprecated_for_removal=True)
conf.register_opt(opt_1, group='group_1')
conf.register_opt(opt_2, group='group_2')
conf.register_opt(opt_3)
conf(['--config-file', 'config.conf'])
assert conf.group_1.opt_1 == 'bar'
assert conf.group_2.opt_2 == 'eggs'
assert conf.opt_3
Assuming that the file config.conf has the following content:
[group_1] opt1 = bar [DEFAULT] opt_2 = eggs opt_3 = True
the script will succeed, but will log three respective warnings about the given deprecated options.
There are also deprecated_reason and deprecated_since parameters for specifying some additional information about a deprecation.
All the mentioned parameters can be mixed together in any combinations.
Global ConfigOpts
This module also contains a global instance of the ConfigOpts class in order to support a common usage pattern in OpenStack:
from oslo_config import cfg opts = [
cfg.StrOpt('bind_host', default='0.0.0.0'),
cfg.PortOpt('bind_port', default=9292), ] CONF = cfg.CONF CONF.register_opts(opts) def start(server, app):
server.start(app, CONF.bind_port, CONF.bind_host)
Helper Functions
Showing detailed locations for configuration settings
oslo.config can track the location in application and library code where an option is defined, defaults are set, or values are overridden. This feature is disabled by default because it is expensive and incurs a significant performance penalty, but it can be useful for developers tracing down issues with configuration option definitions.
To turn on detailed location tracking, set the environment variable OSLO_CONFIG_SHOW_CODE_LOCATIONS to any non-empty value (for example, "1" or "yes, please") before starting the application, test suite, or script. Then use ConfigOpts.get_location() to access the location data for the option.
Style Guide for Help Strings
This document provides style guidance for writing the required help strings for configuration options using the oslo.config code.
The help strings are parsed from the code to appear in sample configuration files, such as etc/cinder/cinder.conf in the cinder repository. They are also displayed in the OpenStack Configuration Reference.
Examples:
cfg.StrOpt('bind_host',
default='0.0.0.0',
help='IP address to listen on.'),
cfg.PortOpt('bind_port',
default=9292,
help='Port number to listen on.')
Style Guide
- 1.
- Use sentence-style capitalization for help strings: Capitalize or uppercase the first character (see the examples above).
- 2.
- Only use single spaces, no double spaces.
- 3.
- Properly capitalize words. If in doubt check the OpenStack Glossary.
- 4.
- End each segment with a period and write complete sentences if possible. Examples:
cfg.StrOpt('osapi_volume_base_URL',
default=None,
help='Base URL that appears in links to the OpenStack '
'Block Storage API.')
cfg.StrOpt('host',
default=socket.gethostname(),
help='Name of this node. This can be an opaque identifier. '
'It is not necessarily a host name, FQDN, or IP address.')
- 5.
- Use valid service names and API names. Valid service names include nova,
cinder, swift, glance, heat, neutron, trove, ceilometer, horizon,
keystone, and marconi.
Valid API names include Compute API, Image Service API, Identity Service API, Object Storage API, Block Storage API, Database API, and Networking API.
Format
- 1.
- For multi-line strings, remember that strings are concatenated directly
and thus spaces need to be inserted normally.
This document recommends to add the space at the end of a line and not at the beginning. Example:
cfg.BoolOpt('glance_api_ssl_compression',
default=False,
help='Enables or disables negotiation of SSL layer '
'compression. In some cases disabling compression '
'can improve data throughput, such as when high '
'network bandwidth is available and you use '
'compressed image formats like qcow2.')
- 2.
- It is possible to preformat the multi-line strings to increase readability. Line break characters \n will be kept as they are used in the help text. Example:
cfg.IntOpt('sync_power_state_interval',
default=600,
help='Interval to sync power states between the database and '
'the hypervisor.\n'
'\n'
'-1: disables the sync \n'
' 0: run at the default rate.\n'
'>0: the interval in seconds')
Enabling your project for mutable config
As of OpenStack Newton, config options can be marked as 'mutable'. This means they can be reloaded (usually via SIGHUP) at runtime, without a service restart. However, each project has to be enabled before this will work and some care needs to be taken over how each option is used before it can safely be marked mutable.
Table of Contents
- Calling mutate_config_files
- Making options mutable-safe
- The option is checked every time
- The option is cached on the stack
- The option affects state
Calling mutate_config_files
Config mutation is triggered by ConfigOpts#mutate_config_files being called. Services launched with oslo.service get a signal handler on SIGHUP but by default that calls the older ConfigOpts#reload_config_files method. To get the new behaviour, we have to pass restart_method='mutate'. For example:
service.ProcessLauncher(CONF, restart_method='mutate')
An example patch is here: https://review.openstack.org/#/c/280851
Some projects may call reload_config_files directly, in this case just change that call to mutate_config_files. If there is no signal handler or you want to trigger reload by a different method, maybe via a web UI or watching a file, just ensure your trigger calls mutate_config_files.
Making options mutable-safe
When options are mutated, they change in the ConfigOpts object but this will not necessarily affect your service immediately. There are three main cases to deal with:
- The option is checked every time
- The option is cached on the stack
- The option affects state
The option is checked every time
This pattern is already safe. Example code:
while True:
progress_timeout = CONF.libvirt.live_migration_progress_timeout
completion_timeout = int(
CONF.libvirt.live_migration_completion_timeout * data_gb)
if libvirt_migrate.should_abort(instance, now, progress_time,
progress_timeout, completion_timeout):
guest.abort_job()
The option is cached on the stack
Just putting the option value in a local variable is enough to cache it. This is tempting to do with loops. Example code:
progress_timeout = CONF.libvirt.live_migration_progress_timeout completion_timeout = int(
CONF.libvirt.live_migration_completion_timeout * data_gb) while True:
if libvirt_migrate.should_abort(instance, now, progress_time,
progress_timeout, completion_timeout):
guest.abort_job()
The goal is to check the option exactly once every time it could have an effect. Usually this is as simple as checking it every time, for example by moving the locals into the loop. Example patch: https://review.openstack.org/#/c/319203
Sometimes multiple computations have to be performed using the option values and it's important that the result is consistent. In this case, it's necessary to cache the option values in locals. Example patch: https://review.openstack.org/#/c/319254
The option affects state
An option value can also be cached, after a fashion, by state - either system or external. For example, the 'debug' option of oslo.log is used to set the default log level on startup. The option is not normally checked again, so if it is mutated, the system state will not reflect the new value of the option. In this case we have to use a mutate hook:
def _mutate_hook(conf, fresh):
if (None, 'debug') in fresh:
if conf.debug:
log_root.setLevel(logging.DEBUG) def register_options(conf):
... snip ...
conf.register_mutate_hook(_mutate_hook)
Mutate hook functions will be passed two positional parameters, 'conf' and 'fresh'. 'conf' is a reference to the updated ConfigOpts object. 'fresh' looks like:
{ (group, option_name): (old_value, new_value), ... }
for example:
{ (None, 'debug'): (False, True),
('libvirt', 'live_migration_progress_timeout'): (50, 75) }
Hooks may be called in any order.
Each project should register one hook, which does whatever is necessary to apply all the new option values. This hook function could grow very large. For good style, modularise the hook using secondary functions rather than accreting a monolith or registering multiple hooks.
Example patch: https://review.openstack.org/#/c/254821/
Option Setting Locations
The get_location() method of ConfigOpts can be used to determine where the value for an option was set, either by the user or by the application code. The return value is a LocationInfo instance, which includes 2 fields: location and detail.
The location value is a member of the Locations enum, which has 5 possible values. The detail value is a string describing the location. Its value depends on the location.
| Value | is_user_controlled | Description | detail |
| opt_default | False | The original default set when the option was defined. | The source file name where the option is defined. |
| set_default | False | A default value set by the application as an override of the original default. This usually only applies to options defined in libraries. | The source file name where set_default() or set_defaults() was called. |
| set_override | False | A forced value set by the application. | The source file name where set_override() was called. |
| user | True | A value set by the user through a configuration backend such as a file. | The configuration file where the option is set. |
| command_line | True | A value set by the user on the command line. | Empty string. |
| environment | True | A value set by the user in the process environment. | The name of the environment variable. |
Did a user set a configuration option?
Each Locations enum value has a boolean property indicating whether that type of location is managed by the user. This eliminates the need for application code to track which types of locations are user-controlled separately.
loc = CONF.get_location('normal_opt').location
if loc.is_user_controlled:
print('normal_opt was set by the user')
else:
print('normal_opt was set by the application')
Sphinx Integration
The oslo_config.sphinxext module defines a custom domain for documenting configuration options. The domain includes a directive and two roles.
- .. show-options::
- Given a list of namespaces, show all of the options exported from them.
.. show-options::
oslo.config
oslo.log
To show each namespace separately, add the split-namespaces flag.
.. show-options::
:split-namespaces:
oslo.config
oslo.log
To use an existing configuration file for the sample configuration generator, use the config-file option instead of specifying the namespaces inline.
.. show-options::
:config-file: etc/oslo-config-generator/glance-api.conf
- :option:
- Link to an option.
#. :oslo.config:option:`config_file` #. :oslo.config:option:`DEFAULT.config_file`
- 1.
- config_file
- 2.
- DEFAULT.config_file
- :group:
- Link to an option group.
:oslo.config:group:`DEFAULT`
DEFAULT
Sphinx Oslo Sample Config Generation
Included with oslo.config is a sphinx extension to generate a sample config file at the beginning of each sphinx build. To activate the extension add oslo_config.sphinxconfiggen to the list of extensions in your sphinx conf.py.
Then you just need to use the config_generator_config_file option to point the config generator at the config file which tells it how to generate the sample config. If one isn't specified or it doesn't point to a real file the sample config file generation will be skipped.
To generate multiple files, set config_generator_config_file to a list of tuples containing the input filename and the base name for the output file.
The output value can be None, in which case the name is taken from the input value.
The input name can be an full path or a value relative to the documentation source directory.
For example:
config_generator_config_file = [
('../../etc/glance-api.conf', 'api'),
('../../etc/glance-cache.conf', 'cache'),
('../../etc/glance-glare.conf', None),
('../../etc/glance-registry.conf', None),
('../../etc/glance-scrubber.conf', None), ]
Produces the output files api.conf.sample, cache.conf.sample, glance-glare.conf.sample, glance-registry.conf.sample, and glance-scrubber.conf.sample.
Output File Name
By default the sphinx plugin will generate the sample config file and name the file sample.config. However, if for whatever reason you'd like the name to be more specific to the project name you can use the sample_config_basename config option to specify the project name. If it's set the output filename will be that value with a .conf.sample extension. For example if you set the value to "nova" the output filename will be "nova.conf.sample". You can also include a subdirectory off of the documentation source directory as part of this value.
Backend Drivers
Refer to oslo_config.sources
Known Backend Drivers
Remote File
The remote_file backend driver is the first driver implemented by oslo.config. It extends the previous limit of only accessing local files to a new scenario where it is possible to access configuration data over the network. The remote_file driver is based on the requests module and is capable of accessing remote files through HTTP or HTTPS.
To definition of a remote_file configuration data source can be as minimal as:
[DEFAULT] config_source = external_config_group [external_config_group] driver = remote_file uri = http://mydomain.com/path/to/config/data.conf
Or as complete as:
[DEFAULT] config_source = external_config_group [external_config_group] driver = remote_file uri = https://mydomain.com/path/to/config/data.conf ca_path = /path/to/server/ca.pem client_key = /path/to/my/key.pem client_cert = /path/to/my/cert.pem
On the following sessions, you can find more information about this driver's classes and its options.
The Driver Class
- class oslo_config.sources._uri.URIConfigurationSourceDriver
- A backend driver for remote files served through http[s].
- Required options:
- •
- uri: URI containing the file location.
- Non-required options:
- •
- ca_path: The path to a CA_BUNDLE file or directory with
- certificates of trusted CAs.
- •
- client_cert: Client side certificate, as a single file path
- containing either the certificate only or the private key and the certificate.
- •
- client_key: Client side private key, in case client_cert is
- specified but does not includes the private key.
The Configuration Source Class
- class oslo_config.sources._uri.URIConfigurationSource(uri, ca_path=None, client_cert=None, client_key=None, timeout=60)
- A configuration source for remote files served through http[s].
- Parameters
- uri -- The Uniform Resource Identifier of the configuration to be retrieved.
- ca_path -- The path to a CA_BUNDLE file or directory with certificates of trusted CAs.
- client_cert -- Client side certificate, as a single file path containing either the certificate only or the private key and the certificate.
- client_key -- Client side private key, in case client_cert is specified but does not includes the private key.
Environment
The environment backend driver provides a method of accessing configuration data in environment variables. It is enabled by default and requires no additional configuration to use. The environment is checked after command line options, but before configuration files.
Environment variables are checked for any configuration data. The variable names take the form:
- A prefix of OS_
- The group name, uppercased
- Separated from the option name by a __ (double underscore)
- Followed by the name
For an option that looks like this in the usual INI format:
[placement_database] connection = sqlite:///
the corresponding environment variable would be OS_PLACEMENT_DATABASE__CONNECTION.
The Driver Class
- class oslo_config.sources._environment.EnvironmentConfigurationSourceDriver
- A backend driver for environment variables.
This configuration source is available by default and does not need special configuration to use. The sample config is generated automatically but is not necessary.
The Configuration Source Class
- class oslo_config.sources._environment.EnvironmentConfigurationSource
- A configuration source for options in the environment.
Frequently Asked Questions
Why does oslo.config have a CONF object? Global objects SUCK!
Indeed. Well, it's a long story and well documented in mailing list archives if anyone cares to dig up some links.
Around the time of the Folsom Design Summit, an attempt was made to remove our dependence on a global object like this. There was massive debate and, in the end, the rough consensus was to stick with using this approach.
Nova, through its use of the gflags library, used this approach from commit zero. Some OpenStack projects didn't initially use this approach, but most now do. The idea is that having all projects use the same approach is more important than the objections to the approach. Sharing code between projects is great, but by also having projects use the same idioms for stuff like this it makes it much easier for people to work on multiple projects.
This debate will probably never completely go away, though. See this latest discussion in August, 2014
Why are configuration options not part of a library's API?
Configuration options are a way for deployers to change the behavior of OpenStack. Applications are not supposed to be aware of the configuration options defined and used within libraries, because the library API is supposed to work transparently no matter which backend is configured.
Configuration options in libraries can be renamed, moved, and deprecated just like configuration options in applications. However, if applications are allowed to read or write the configuration options directly, treating them as an API, the option cannot be renamed without breaking the application. Instead, libraries should provide a programmatic API (usually a set_defaults() function) for setting the defaults for configuration options. For example, this function from oslo.log lets the caller change the format string and default logging levels:
def set_defaults(logging_context_format_string=None,
default_log_levels=None):
"""Set default values for the configuration options used by oslo.log."""
# Just in case the caller is not setting the
# default_log_level. This is insurance because
# we introduced the default_log_level parameter
# later in a backwards in-compatible change
if default_log_levels is not None:
cfg.set_defaults(
_options.log_opts,
default_log_levels=default_log_levels)
if logging_context_format_string is not None:
cfg.set_defaults(
_options.log_opts,
logging_context_format_string=logging_context_format_string)
If the name of either option changes, the API of set_defaults() can be updated to allow both names, and warn if the old one is provided. Using a supported API like this is better than having an application call set_default() on the configuration object directly, such as:
cfg.CONF.set_default('default_log_levels', default_log_levels)
This form will trigger an error if the logging options are moved out of the default option group into their own section of the configuration file. It will also fail if the default_log_levels option is not yet registered, or if it is renamed. All of those cases can be protected against with a set_defaults() function in the library that owns the options.
Similarly, code that does not own the configuration option definition should not read the option value. An application should never, for example, do something like:
log_file = cfg.CONF.log_file
The type, name, and existence of the log_file configuration option is subject to change. oslo.config makes it easy to communicate that change to a deployer in a way that allows their old configuration files to continue to work. It has no mechanism for doing that in application code, however.
oslo.config Command Line Tools
oslo-config-generator
oslo-config-generator is a utility for generating sample config files in a variety of formats. Sample config files list all of the available options, along with their help string, type, deprecated aliases and defaults. These sample files can be used as config files for oslo.config itself (ini) or by configuration management tools (json, yaml).
Added in version 1.4.0.
Changed in version 4.3.0: The oslo-config-generator --format parameter was added, which allows outputting in additional formats.
Usage
oslo-config-generator
--namespace <namespace> [--namespace <namespace> ...]
[--output-file <output-file>]
[--wrap-width <wrap-width>]
[--format <format>]
[--minimal]
[--summarize]
- --namespace <namespace>
- Option namespace under oslo.config.opts in which to query for options.
- --output-file <output-file>
- Path of the file to write to.
- Default
- stdout
- --wrap-width <wrap-width>
- The maximum length of help lines.
- Default
- 70
- --format <format>
- Desired format for the output. ini is the only format that can be used directly with oslo.config. json and yaml are intended for third-party tools that want to write config files based on the sample config data. For more information, refer to Generating Machine Readable Configs.
- Choices
- ini, json, yaml
- --minimal
- Generate a minimal required configuration.
- --summarize
- Only output summaries of help text to config files. Retain longer help text for Sphinx documents.
For example, to generate a sample config file for oslo.messaging you would run:
$ oslo-config-generator --namespace oslo.messaging > oslo.messaging.conf
To generate a sample config file for an application myapp that has its own options and uses oslo.messaging, you would list both namespaces:
$ oslo-config-generator --namespace myapp \
--namespace oslo.messaging > myapp.conf
To generate a sample config file for oslo.messaging in JSON format, you would run:
$ oslo-config-generator --namespace oslo.messaging \
--format json > oslo.messaging.conf
Defining Option Discovery Entry Points
The oslo-config-generator --namespace option specifies an entry point name registered under the oslo.config.opts entry point namespace. For example, in the oslo.messaging setup.cfg we have:
[entry_points] oslo.config.opts =
oslo.messaging = oslo.messaging.opts:list_opts
The callable referenced by the entry point should take no arguments and return a list of (group, [opt_1, opt_2]) tuples, where group is either a group name as a string or an OptGroup object. Passing the OptGroup object allows the consumer of the list_opts method to access and publish group help. An example, using both styles:
from oslo_config import cfg opts1 = [
cfg.StrOpt('foo'),
cfg.StrOpt('bar'), ] opts2 = [
cfg.StrOpt('baz'), ] baz_group = cfg.OptGroup(name='baz_group'
title='Baz group options',
help='Baz group help text') cfg.CONF.register_group(baz_group) cfg.CONF.register_opts(opts1, group='blaa') cfg.CONF.register_opts(opts2, group=baz_group) def list_opts():
# Allows the generation of the help text for
# the baz_group OptGroup object. No help
# text is generated for the 'blaa' group.
return [('blaa', opts1), (baz_group, opts2)]
NOTE:
The module holding the entry point must be importable, even if the dependencies of that module are not installed. For example, driver modules that define options but have optional dependencies on third-party modules must still be importable if those modules are not installed. To accomplish this, the optional dependency can either be imported using oslo.utils.importutils.try_import() or the option definitions can be placed in a file that does not try to import the optional dependency.
Modifying Defaults from Other Namespaces
Occasionally applications need to override the defaults for options defined in libraries. At runtime this is done using an API within the library. Since the config generator cannot guarantee the order in which namespaces will be imported, we can't ensure that application code can change the option defaults before the generator loads the options from a library. Instead, a separate optional processing hook is provided for applications to register a function to update default values after all options are loaded.
The hooks are registered in a separate entry point namespace (oslo.config.opts.defaults), using the same entry point name as the application's list_opts() function.
[entry_points] oslo.config.opts.defaults =
keystone = keystone.common.config:update_opt_defaults
WARNING:
In this case, the name of the entry point for the default override function must match the name of one of the entry points defining options for the application in order to be detected and used. Applications that have multiple list_opts functions should use one that is present in the inputs for the config generator where the changed defaults need to appear. For example, if an application defines foo.api to list the API-related options, and needs to override the defaults in the oslo.middleware.cors library, the application should register foo.api under oslo.config.opts.defaults and point to a function within the application code space that changes the defaults for oslo.middleware.cors.
The update function should take no arguments. It should invoke the public set_defaults() functions in any libraries for which it has option defaults to override, just as the application does during its normal startup process.
from oslo_log import log def update_opt_defaults():
log.set_defaults(
default_log_levels=log.get_default_log_levels() + ['noisy=WARN'],
)
Generating Machine Readable Configs
All deployment tools have to solve a similar problem: how to generate the config files for each service at deployment time. To help with this problem, oslo-config-generator can generate machine-readable sample config files that output the same data as the INI files used by oslo.config itself, but in a YAML or JSON format that can be more easily consumed by deployment tools.
IMPORTANT:
For example, some YAML-formatted output might look like so:
generator_options:
config_dir: []
config_file: []
format_: yaml
minimal: false
namespace:
- keystone
output_file: null
summarize: false
wrap_width: 70 options:
DEFAULT:
help: ''
opts:
- advanced: false
choices: []
default: null
deprecated_for_removal: false
deprecated_opts: []
deprecated_reason: null
deprecated_since: null
dest: admin_token
help: Using this feature is *NOT* recommended. Instead, use the `keystone-manage
bootstrap` command. The value of this option is treated as a "shared secret"
that can be used to bootstrap Keystone through the API. This "token" does
not represent a user (it has no identity), and carries no explicit authorization
(it effectively bypasses most authorization checks). If set to `None`, the
value is ignored and the `admin_token` middleware is effectively disabled.
However, to completely disable `admin_token` in production (highly recommended,
as it presents a security risk), remove `AdminTokenAuthMiddleware` (the `admin_token_auth`
filter) from your paste application pipelines (for example, in `keystone-paste.ini`).
max: null
metavar: null
min: null
mutable: false
name: admin_token
namespace: keystone
positional: false
required: false
sample_default: null
secret: true
short: null
type: string value
- ...
... deprecated_options:
DEFAULT:
- name: bind_host
replacement_group: eventlet_server
replacement_name: public_bind_host
where the top-level keys are:
generator_options
options
For information on the various attributes of each option, refer to oslo_config.cfg.Opt and its subclasses.
deprecated_options
Generating Multiple Sample Configs
A single codebase might have multiple programs, each of which use a subset of the total set of options registered by the codebase. In that case, you can register multiple entry points:
[entry_points] oslo.config.opts =
nova.common = nova.config:list_common_opts
nova.api = nova.config:list_api_opts
nova.compute = nova.config:list_compute_opts
and generate a config file specific to each program:
$ oslo-config-generator --namespace oslo.messaging \
--namespace nova.common \
--namespace nova.api > nova-api.conf $ oslo-config-generator --namespace oslo.messaging \
--namespace nova.common \
--namespace nova.compute > nova-compute.conf
To make this more convenient, you can use config files to describe your config files:
$ cat > config-generator/api.conf <<EOF [DEFAULT] output_file = etc/nova/nova-api.conf namespace = oslo.messaging namespace = nova.common namespace = nova.api EOF $ cat > config-generator/compute.conf <<EOF [DEFAULT] output_file = etc/nova/nova-compute.conf namespace = oslo.messaging namespace = nova.common namespace = nova.compute EOF $ oslo-config-generator --config-file config-generator/api.conf $ oslo-config-generator --config-file config-generator/compute.conf
Sample Default Values
The default runtime values of configuration options are not always the most suitable values to include in sample config files - for example, rather than including the IP address or hostname of the machine where the config file was generated, you might want to include something like 10.0.0.1. To facilitate this, options can be supplied with a sample_default attribute:
cfg.StrOpt('base_dir'
default=os.getcwd(),
sample_default='/usr/lib/myapp')
oslo-config-validator
oslo-config-validator is a utility for verifying that the entries in a config file are correct. It will report an error for any options found that are not defined by the service, and a warning for any deprecated options found.
Added in version 6.5.0.
Usage
There are two primary ways to use the config validator. It can use the sample config generator configuration file found in each service to determine the list of available options, or it can consume a machine-readable sample config that provides the same information.
Sample Config Generator Configuration
NOTE:
There are two parameters that must be passed to the validator in this case: --config-file and --input-file. --config-file should point at the location of the sample config generator configuration file, while --input-file should point at the location of the configuration file to be validated.
Here's an example of using the validator on Nova as installed by Devstack (with the option [foo]/bar added to demonstrate a failure):
$ oslo-config-validator --config-file /opt/stack/nova/etc/nova/nova-config-generator.conf --input-file /etc/nova/nova.conf ERROR:root:foo/bar is not part of the sample config INFO:root:Ignoring missing option "project_domain_name" from group "keystone_authtoken" because the group is known to have incomplete sample config data and thus cannot be validated properly. INFO:root:Ignoring missing option "project_name" from group "keystone_authtoken" because the group is known to have incomplete sample config data and thus cannot be validated properly. INFO:root:Ignoring missing option "user_domain_name" from group "keystone_authtoken" because the group is known to have incomplete sample config data and thus cannot be validated properly. INFO:root:Ignoring missing option "password" from group "keystone_authtoken" because the group is known to have incomplete sample config data and thus cannot be validated properly. INFO:root:Ignoring missing option "username" from group "keystone_authtoken" because the group is known to have incomplete sample config data and thus cannot be validated properly. INFO:root:Ignoring missing option "auth_url" from group "keystone_authtoken" because the group is known to have incomplete sample config data and thus cannot be validated properly.
Machine-Readable Sample Config
NOTE:
In this case, a machine-readable sample config must first be generated, as described in oslo-config-generator.
This file is then passed to the validator with --opt-data, along with the config file to validated in --input-file as above.
Here's an example of using the validator on Nova as installed by Devstack, with a sample config file config-data.yaml created by the config generator (with the option [foo]/bar added to demonstrate a failure):
$ oslo-config-validator --opt-data config-data.yaml --input-file /etc/nova/nova.conf ERROR:root:foo/bar is not part of the sample config INFO:root:Ignoring missing option "project_domain_name" from group "keystone_authtoken" because the group is known to have incomplete sample config data and thus cannot be validated properly. INFO:root:Ignoring missing option "project_name" from group "keystone_authtoken" because the group is known to have incomplete sample config data and thus cannot be validated properly. INFO:root:Ignoring missing option "user_domain_name" from group "keystone_authtoken" because the group is known to have incomplete sample config data and thus cannot be validated properly. INFO:root:Ignoring missing option "password" from group "keystone_authtoken" because the group is known to have incomplete sample config data and thus cannot be validated properly. INFO:root:Ignoring missing option "username" from group "keystone_authtoken" because the group is known to have incomplete sample config data and thus cannot be validated properly. INFO:root:Ignoring missing option "auth_url" from group "keystone_authtoken" because the group is known to have incomplete sample config data and thus cannot be validated properly.
Comparing configuration with the default configuration
NOTE:
Comparing the default configuration with the current configuration can help operators with troubleshooting issues. Since the generator config is not always available in production environment, we can pass the --namespace arguments. In addition to the --namespace, we need to pass a --input-file as well as the --check-defaults.
Some options are ignored by default but this behavior can be overridden with the --exclude-options list argument.
Here's an example of using the validator on Nova:
$ oslo-config-validator --input-file /etc/nova/nova.conf \
--check-defaults \
--namespace nova.conf \
--namespace oslo.log \
--namespace oslo.messaging \
--namespace oslo.policy \
--namespace oslo.privsep \
--namespace oslo.service.periodic_task \
--namespace oslo.service.service \
--namespace oslo.db \
--namespace oslo.middleware \
--namespace oslo.concurrency \
--namespace keystonemiddleware.auth_token \
--namespace osprofiler INFO:keyring.backend:Loading Gnome INFO:keyring.backend:Loading Google INFO:keyring.backend:Loading Windows (alt) INFO:keyring.backend:Loading file INFO:keyring.backend:Loading keyczar INFO:keyring.backend:Loading multi INFO:keyring.backend:Loading pyfs WARNING:root:DEFAULT/compute_driver sample value is empty but input-file has libvirt.LibvirtDriver WARNING:root:DEFAULT/allow_resize_to_same_host sample value is empty but input-file has True WARNING:root:DEFAULT/default_ephemeral_format sample value is empty but input-file has ext4 WARNING:root:DEFAULT/pointer_model sample value ['usbtablet'] is not in ['ps2mouse'] WARNING:root:DEFAULT/instances_path sample value ['$state_path/instances'] is not in ['/opt/stack/data/nova/instances'] WARNING:root:DEFAULT/shutdown_timeout sample value ['60'] is not in ['0'] INFO:root:DEFAULT/my_ip Ignoring option because it is part of the excluded patterns. This can be changed with the --exclude-options argument. WARNING:root:DEFAULT/state_path sample value ['$pybasedir'] is not in ['/opt/stack/data/nova'] INFO:root:DEFAULT/osapi_compute_listen Ignoring option because it is part of the excluded patterns. This can be changed with the --exclude-options argument. WARNING:root:DEFAULT/osapi_compute_workers sample value is empty but input-file has 2 WARNING:root:DEFAULT/metadata_workers sample value is empty but input-file has 2 WARNING:root:DEFAULT/graceful_shutdown_timeout sample value ['60'] is not in ['5'] INFO:root:DEFAULT/transport_url Ignoring option because it is part of the excluded patterns. This can be changed with the --exclude-options argument. WARNING:root:DEFAULT/debug sample value is empty but input-file has True WARNING:root:DEFAULT/logging_context_format_string sample value ['%(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [%(request_id)s %(user_identity)s] %(instance)s%(message)s'] is not in ['%(color)s%(levelname)s %(name)s [\x1b[01;36m%(global_request_id)s %(request_id)s \x1b[00;36m%(project_name)s %(user_name)s%(color)s] \x1b[01;35m%(instance)s%(color)s%(message)s\x1b[00m'] WARNING:root:DEFAULT/logging_default_format_string sample value ['%(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [-] %(instance)s%(message)s'] is not in ['%(color)s%(levelname)s %(name)s [\x1b[00;36m-%(color)s] \x1b[01;35m%(instance)s%(color)s%(message)s\x1b[00m'] WARNING:root:DEFAULT/logging_debug_format_suffix sample value ['%(funcName)s %(pathname)s:%(lineno)d'] is not in ['\x1b[00;33m{{(pid=%(process)d) %(funcName)s %(pathname)s:%(lineno)d}}\x1b[00m'] WARNING:root:DEFAULT/logging_exception_prefix sample value ['%(asctime)s.%(msecs)03d %(process)d ERROR %(name)s %(instance)s'] is not in ['ERROR %(name)s \x1b[01;35m%(instance)s\x1b[00m'] WARNING:root:Group api from the sample config is not defined in input-file WARNING:root:cache/backend sample value ['dogpile.cache.null'] is not in ['dogpile.cache.memcached'] WARNING:root:cache/enabled sample value is empty but input-file has True WARNING:root:cinder/os_region_name sample value is empty but input-file has RegionOne WARNING:root:cinder/auth_type sample value is empty but input-file has password INFO:root:cinder/auth_url Ignoring option because it is part of the excluded patterns. This can be changed with the --exclude-options argument. WARNING:root:cinder/project_name sample value is empty but input-file has service WARNING:root:cinder/project_domain_name sample value is empty but input-file has Default INFO:root:cinder/username Ignoring option because it is part of the excluded patterns. This can be changed with the --exclude-options argument. WARNING:root:cinder/user_domain_name sample value is empty but input-file has Default INFO:root:cinder/password Ignoring option because it is part of the excluded patterns. This can be changed with the --exclude-options argument. WARNING:root:Group compute from the sample config is not defined in input-file WARNING:root:conductor/workers sample value is empty but input-file has 2 WARNING:root:Group console from the sample config is not defined in input-file WARNING:root:Group consoleauth from the sample config is not defined in input-file WARNING:root:Group cyborg from the sample config is not defined in input-file INFO:root:api_database/connection Ignoring option because it is part of the excluded patterns. This can be changed with the --exclude-options argument. WARNING:root:Group devices from the sample config is not defined in input-file WARNING:root:Group ephemeral_storage_encryption from the sample config is not defined in input-file WARNING:root:Group glance from the sample config is not defined in input-file WARNING:root:Group guestfs from the sample config is not defined in input-file WARNING:root:Group hyperv from the sample config is not defined in input-file WARNING:root:Group image_cache from the sample config is not defined in input-file WARNING:root:Group ironic from the sample config is not defined in input-file WARNING:root:key_manager/fixed_key sample value is empty but input-file has bae3516cc1c0eb18b05440eba8012a4a880a2ee04d584a9c1579445e675b12defdc716ec WARNING:root:key_manager/backend sample value ['barbican'] is not in ['nova.keymgr.conf_key_mgr.ConfKeyManager'] WARNING:root:Group barbican from the sample config is not defined in input-file WARNING:root:Group vault from the sample config is not defined in input-file WARNING:root:Group keystone from the sample config is not defined in input-file INFO:root:libvirt/live_migration_uri Ignoring option because it is part of the excluded patterns. This can be changed with the --exclude-options argument. WARNING:root:libvirt/cpu_mode sample value is empty but input-file has none WARNING:root:Group mks from the sample config is not defined in input-file WARNING:root:neutron/default_floating_pool sample value ['nova'] is not in ['public'] WARNING:root:neutron/service_metadata_proxy sample value is empty but input-file has True WARNING:root:neutron/auth_type sample value is empty but input-file has password INFO:root:neutron/auth_url Ignoring option because it is part of the excluded patterns. This can be changed with the --exclude-options argument. WARNING:root:neutron/project_name sample value is empty but input-file has service WARNING:root:neutron/project_domain_name sample value is empty but input-file has Default INFO:root:neutron/username Ignoring option because it is part of the excluded patterns. This can be changed with the --exclude-options argument. WARNING:root:neutron/user_domain_name sample value is empty but input-file has Default INFO:root:neutron/password Ignoring option because it is part of the excluded patterns. This can be changed with the --exclude-options argument. WARNING:root:neutron/region_name sample value is empty but input-file has RegionOne WARNING:root:Group pci from the sample config is not defined in input-file WARNING:root:placement/auth_type sample value is empty but input-file has password INFO:root:placement/auth_url Ignoring option because it is part of the excluded patterns. This can be changed with the --exclude-options argument. WARNING:root:placement/project_name sample value is empty but input-file has service WARNING:root:placement/project_domain_name sample value is empty but input-file has Default INFO:root:placement/username Ignoring option because it is part of the excluded patterns. This can be changed with the --exclude-options argument. WARNING:root:placement/user_domain_name sample value is empty but input-file has Default INFO:root:placement/password Ignoring option because it is part of the excluded patterns. This can be changed with the --exclude-options argument. WARNING:root:placement/region_name sample value is empty but input-file has RegionOne WARNING:root:Group powervm from the sample config is not defined in input-file WARNING:root:Group quota from the sample config is not defined in input-file WARNING:root:Group rdp from the sample config is not defined in input-file WARNING:root:Group remote_debug from the sample config is not defined in input-file WARNING:root:scheduler/workers sample value is empty but input-file has 2 WARNING:root:filter_scheduler/track_instance_changes sample value ['True'] is not in ['False'] WARNING:root:filter_scheduler/enabled_filters sample value ['AvailabilityZoneFilter', 'ComputeFilter', 'ComputeCapabilitiesFilter', 'ImagePropertiesFilter', 'ServerGroupAntiAffinityFilter', 'ServerGroupAffinityFilter'] is not in ['AvailabilityZoneFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,SameHostFilter,DifferentHostFilter'] WARNING:root:Group metrics from the sample config is not defined in input-file WARNING:root:Group serial_console from the sample config is not defined in input-file WARNING:root:Group service_user from the sample config is not defined in input-file WARNING:root:Group spice from the sample config is not defined in input-file WARNING:root:upgrade_levels/compute sample value is empty but input-file has auto WARNING:root:Group vendordata_dynamic_auth from the sample config is not defined in input-file WARNING:root:Group vmware from the sample config is not defined in input-file WARNING:root:Group vnc from the sample config is not defined in input-file WARNING:root:Group workarounds from the sample config is not defined in input-file WARNING:root:wsgi/api_paste_config sample value ['api-paste.ini'] is not in ['/etc/nova/api-paste.ini'] WARNING:root:Group zvm from the sample config is not defined in input-file WARNING:root:oslo_concurrency/lock_path sample value is empty but input-file has /opt/stack/data/nova WARNING:root:Group oslo_middleware from the sample config is not defined in input-file WARNING:root:Group cors from the sample config is not defined in input-file WARNING:root:Group healthcheck from the sample config is not defined in input-file WARNING:root:Group oslo_messaging_amqp from the sample config is not defined in input-file WARNING:root:oslo_messaging_notifications/driver sample value is empty but input-file has messagingv2 INFO:root:oslo_messaging_notifications/transport_url Ignoring option because it is part of the excluded patterns. This can be changed with the --exclude-options argument. WARNING:root:Group oslo_messaging_rabbit from the sample config is not defined in input-file WARNING:root:Group oslo_messaging_kafka from the sample config is not defined in input-file WARNING:root:Group oslo_policy from the sample config is not defined in input-file WARNING:root:Group privsep from the sample config is not defined in input-file WARNING:root:Group profiler from the sample config is not defined in input-file INFO:root:database/connection Ignoring option because it is part of the excluded patterns. This can be changed with the --exclude-options argument. WARNING:root:keystone_authtoken/interface sample value ['internal'] is not in ['public'] WARNING:root:keystone_authtoken/cafile sample value is empty but input-file has /opt/stack/data/ca-bundle.pem WARNING:root:keystone_authtoken/memcached_servers sample value is empty but input-file has localhost:11211 WARNING:root:keystone_authtoken/auth_type sample value is empty but input-file has password ERROR:root:neutron/auth_strategy is not part of the sample config INFO:root:Ignoring missing option "project_domain_name" from group "keystone_authtoken" because the group is known to have incomplete sample config data and thus cannot be validated properly. INFO:root:Ignoring missing option "project_name" from group "keystone_authtoken" because the group is known to have incomplete sample config data and thus cannot be validated properly. INFO:root:Ignoring missing option "user_domain_name" from group "keystone_authtoken" because the group is known to have incomplete sample config data and thus cannot be validated properly. INFO:root:Ignoring missing option "password" from group "keystone_authtoken" because the group is known to have incomplete sample config data and thus cannot be validated properly. INFO:root:Ignoring missing option "username" from group "keystone_authtoken" because the group is known to have incomplete sample config data and thus cannot be validated properly. INFO:root:Ignoring missing option "auth_url" from group "keystone_authtoken" because the group is known to have incomplete sample config data and thus cannot be validated properly
Handling Dynamic Groups
Some services register group names dynamically at runtime based on other configuration. This is problematic for the validator because these groups won't be present in the sample config data. The --exclude-group option for the validator can be used to ignore such groups and allow the other options in a config file to be validated normally.
NOTE:
Contributing
If you would like to contribute to the development of oslo's libraries, first you must take a look to this page:
If you would like to contribute to the development of OpenStack, start by following the steps in this page:
Once those steps have been completed, changes to OpenStack should be submitted for review via the Gerrit tool, following the workflow documented at:
Pull requests submitted through GitHub will be ignored.
Bugs should be filed on Launchpad, not GitHub:
RELEASE NOTES
Read also the oslo.config Release Notes.
INDICES AND TABLES
- Index
- Module Index
- Search Page
AUTHOR
Author name not set
COPYRIGHT
2025, OpenStack Foundation
| April 2, 2025 | 9.7.1 |
