Openstack configuration module

Reproduced in: http://www.choudan.net/2013/11/27/OpenStack-Oslo.config-%E5%AD%A6%E4%B9%A0 (%e4%b8%80%.html

The Oslo project provides a series of libraries. The library we use most is Oslo. config, which is used to process program command line parameters and configuration files.

I. Introduction to Oslo. config

Before the G version of openstack, almost every project has to copy the cfg. py file and put the iniparser. py fileopenstack/common/Directory, these two files are mainly used to solve the problem of reading the configuration file and parsing the command line parameters. In actual use of openstack, we start a service, such as Nova-API or glance-API, in this format:

/Usr/bin/NOVA-API-config-file =/etc/NOVA. conf-log-file =/var/log/NOVA/API. Log

From this startup command, we need to be able to process command line parameters correctly, as well as configuration files. Observe carefully and find that different services, such as Nova-API and glance-API, have common command line parameters, such as-config-file and-log-file, then each service has its own command line parameters. There may be multiple configuration files, such as multiple services, Nova-API, and Nova-compute in the Nova project. Therefore, there will be a large number of common configurations between these Nova services. For this reason, Oslo suggests that if multiple configuration files are supported, it will be awesome, like this form:--config-file=/etc/nova/nova-commmon.conf --config-file=/etc/nova/nova-api.conf. Currently, configuration file formats are mainly INI files. In addition to parsing configuration options, another problem is that you can quickly access the values of these configuration options.

Therefore, Oslo. config has been fixed on the Olso. config wiki to solve the following problems:

• Command Line option Parsing
• Common command line options
• Configuration File Parsing
• Option value Lookup

We also mentioned a scenario in wiki. It is recommended that you write some default options values in the Code and annotate them in config file. This should be a lot of commented-out configurations seen in config. These default values can also be seen in the code.

 

Ii. Use Oslo. config

The Oslo. config library has only two files: cfg. py and iniparser. py. The usage of Oslo. config has provided comments in the cfg. py file that are not generally detailed.

1. Options

Options is the so-called configuration option, which can be set through the command line and configuration file. The general form is as follows:

common_opts = [    cfg.StrOpt(‘bind_host‘,                default=‘0.0.0.0‘,                help=‘IP address to listen on‘),    cfg.IntOpt(‘bind_port‘,                default=9292,                help=‘Port number to listen on‘)]

In the general form above, the options name, default value and help information are specified. It can also be seen that different configuration options belong to different types. Stropt, PT. In addition, options also supports floats, booleans, list, dict, and multi strings.

Before these options are referenced, you must register the options through config manager at runtime. For example:

class ExtensionManager(object):    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:        ....

To use the osapi_compute_extension option, you must first register the option through self. conf. register_opt (enabled_apis_opt.

As mentioned above, options can be started in the command line to start the service. These options must be registered through config manager before being parsed by the program. In this way, we can implement common help parameters and confirm the correctness of command line parameters. The registration of command lines is slightly different from the registration method mentioned above. It calls a specific function, Conf. register_cli_opts (cli_opts ).

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)

2. config file

We mentioned earlier that Oslo. config supports the ini-style configuration file, which groups all configuration options, that is, the so-called section or group. These two words are the same concept, if no section is specified, it will be assigned to the default group. The following is an example of an INI-style configuration file:

glance-api.conf:    [DEFAULT]    bind_port = 9292            glance-common.conf:    [DEFAULT]    bind_host = 0.0.0.0

In config manager, two values are specified by default, that is--config-file --config-dir, Config manager will find the default file in the default folder if the two parameters are not displayed. For example~/.${project}， ~/， /etc/${project}，/etc/Search for configuration files in these directories. If the program is Nova, it will find the Nova. conf file in the default path.

Note in the code that,Option values in config files override those on the command line.That is, the option value in config files overwrites the option value in the command line. This seems to be the opposite of the subconscious. English is the original saying.Supplement:, after testing and reading the source code, option values specified on command lines override those in config files should be used. For details, refer to the next analysis.Multiple configuration files will be parsed in order, and the options in the subsequent files will overwrite the previous options.

3. Option Group

In the configuration file, we have seen that many configuration options have been actively divided by a group, and those with no ownership option are thrown to the default group. Similarly, in the Code, options can be displayed to register a group. You can directly specify a group or a group name by using the following code:

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.IntOpt(‘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‘)

We need to define a group, specify the group name and title attributes, and register the group. Finally, we can register options to the group in two ways. If a group only has the name attribute, we do not need to display the registered group. For example, the following code:

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‘)

4. Option Values

To reference the value of an option, you can directly access the config manager attribute. For example, you can access the default group or another group in the following ways:

conf.bind_port  
conf.rabbit.port

At the same time, the option value can also be referenced by using pep 292 string substitution (PEP 292 describes the string replacement method) and other option values. For details, see the following example. In the SQL _connection value, we reference the values of other options.

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‘),]

In some cases, you need to hide the key option value in the log file. You can add the secret parameter when creating this option and set it to true.

5. config Manager

We have already mentioned config manager many times. To use options, you must register options in config manager to access the option value and directly access the attributes of config manager, config Manager manages options in a unified manner. In fact, config manager is a global object. The _ call _ method and the _ getattr _ method are overloaded. The most important thing is that there is only such an instance in the world. at the end of the annotation of Py, a complete example is provided. First, obtain the global instance, register options, and use options.

from oslo.config import cfgopts = [cfg.StrOpt(‘bind_host‘, default=‘0.0.0.0‘),cfg.IntOpt(‘bind_port‘, default=9292),]                        CONF = cfg.CONFCONF.register_opts(opts)                                def start(server, app):    server.start(app, CONF.bind_port, CONF.bind_host)

Reference:

Https://wiki.openstack.org/wiki/Oslo Oslo Wiki

Https://wiki.openstack.org/wiki/Oslo/Config Oslo. config Wiki

Openstack configuration module