openstack配置模块

转载编辑于:http://www.choudan.net/2013/11/27/OpenStack-Oslo.config-%E5%AD%A6%E4%B9%A0(%E4%B8%80).html

  Oslo 项目提供了一系列的库,我们接触的最多的为oslo.config这个库,用来处理程序命令行参数和配置文件。

一、oslo.config简介

  OpenStack在G版之前的几乎每个项目都得拷贝一份cfg.py,iniparser.py两个文件放到openstack/common/目录下,这两个文件主要致力于解决读取配置文件和解析命令行参数的问题。在实际使用OpenStack的过程中,我们启动一个服务,例如nova-api或者glance-api,往往都是这样的形式:

/usr/bin/nova-api –config-file=/etc/nova/nova.conf –log-file=/var/log/nova/api.log

  从这个启动命令来看,我们需要能够正确的处理命令行参数,还有配置文件。细心观察会发现,不同的服务,nova-api,glance-api等等,都会有一些共同的命令行参数,如上面的–config-file,–log-file等等,然后每个服务还有自己专属的命令行参数。对于配置文件,可能存在多个,例如,nova项目存在多个服务,nova-api,nova-compute等等。那么这些nova services之间会存在大量共同的配置,对此,Oslo建议如果支持多个配置文件的话,那么就很给力了,像这个形式:--config-file=/etc/nova/nova-commmon.conf --config-file=/etc/nova/nova-api.conf。对配置文件格式的支持,目前主要是ini风格的文件。除了解析配置选项之外,另一个问题是,快速访问到这些配置选项的值。

  因此,olso.config wiki上贴出了oslo.config需要解决的几点问题:

  • command line option parsing
  • common command line options
  • configuration file parsing
  • option value lookup

  在wiki中还提到一种场景,建议最好将一些options的默认值写在code里面,同时也在config file中作为注释表明。这应该就是在config中看到的很多被注释掉的配置,在代码中同样可以看到这些默认值。

二、oslo.config使用

  oslo.config库只有两个文件,cfg.py和iniparser.py,oslo.config的使用方法在cfg.py文件中已经给出不是一般详细的注释。

1、options

  options 即所谓的配置选项,可以通过命令行和配置文件设置,它一般的形式如下:

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

  上面的一般形式,指定了options的名字,默认值和帮助信息,还可以看出,不同的配置选项属于不同的类型。StrOpt,IntOpt。除此之外,Options还支持floats,booleans,list,dict,multi strings。

  这些options在被引用之前,必须先在运行期通过config manager注册该options,即使用前得先注册。例如下的情况:

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:
        ....

  我们若要使用osapi_compute_extension选项,则需要先通过self.conf.register_opt(enabled_apis_opt)完成option的注册。

  前面我们提到options可以在启动服务的命令行中启动,这些选项在被程序解析之前,必须先通过config manager注册。这样的好处,我们可以实现常用的help参数,并且确认命令行参数的正确性。命令行的注册略微不同前面提到的注册方式,调用的是特定的函数,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

  前面我们提到oslo.config支持的是ini风格的配置文件,该文件将所有的配置选项进行了分组,即所谓的section或者group,这两个单词是同一个概念,没有指定section的,则会分到default组。下面给出了一个ini风格的配置文件例子:

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

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

  在config manager中,会默认的指定两个值,即--config-file --config-dir,config manager会在没有显示指定这两个参数的情况下去默认的文件夹中查找默认的文件。例如~/.${project}, ~/, /etc/${project},/etc/这几个目录下查找配置文件,如果程序是nova,则会查找默认路径下的nova.conf文件。

  在代码中的注释指出,Option values in config files override those on the command line. 即config files中的选项值会覆盖命令行中的选项值。这貌似与潜意识中的相反呀,英文是原话。补充:2013-11-28,经过自己的测试和对源码的阅读,应该是Option values specified on command lines override those in config files,具体参考下一篇的分析。 多个配置文件会按顺序来解析,后面文件中的选项会覆盖前面出现过的选项。

3、option group

  在配置文件中,我们已经看到很多配置选项已经被我们主动的进行了一个分组的划分,没有归属的选项则扔到了default组。同样,在代码中options可以显示的注册某个组中。注册的方式有两种,直接指定group,或者指定group的name,参考下面代码:

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

  我们需要先定义一个group,指定group的name和title属性,也得将group注册,最后可通过两种方式将options注册到该组中。若一个group仅只有name属性,那么我们可以不用显示的注册group,例如下面的代码:

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

  若要引用某个option的值,则直接通过访问config manager属性的方式即可。例如,访问default组或者其他的组,可以通过如下的方式:

conf.bind_port  conf.rabbit.port

  同时,option值还可以通过PEP 292 string substitution(pep 292描述了字符串替换的方式)再引用其他的option的值,具体看下面的例子,在sql_connection值中,我们引用了其他的option的值。

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

  还有在某些情况下,我们需要在日志文件中隐藏关键option的值,可以在创建该option时,添加secret参数,设置为True。

5、config manager

  我们已经多次提到config manager了,要使用options,得先将options注册到config manager中,访问option的值,直接访问config manager的属性,config manager对options进行了统一的管理,其实config manager是一个全局的对象,重载了__call__方法,还有__getattr__方法。最为关键的,全局就只有这么一个实例,在cfg.py的注释尾,再给出了一个完整的例子,首先获取全局的这个实例,然后注册options,最后使用options。

from oslo.config import cfg

opts = [
cfg.StrOpt(‘bind_host‘, default=‘0.0.0.0‘),
cfg.IntOpt(‘bind_port‘, default=9292),
]

CONF = cfg.CONF
CONF.register_opts(opts)

def start(server, app):
    server.start(app, CONF.bind_port, CONF.bind_host)
 

参考文档:

https://wiki.openstack.org/wiki/Oslo Oslo WiKi

https://wiki.openstack.org/wiki/Oslo/Config Oslo.config WiKi

时间: 2024-10-25 18:35:12

openstack配置模块的相关文章

Openstack配置文件管理的变迁之路

在管理一个Openstack集群时,如何维护配置文件无疑是其中最艰难和繁琐的任务之一.因为你不仅要面对众多的核心服务(nova,keystone,glance,cinder,etc)的配置文件,还需要管理其相关服务的配置文件(mysql,rabbitmq,bind9,etc).并且在Openstack组件式的设计架构,以及将功能抽象为plugin或是pipeline中的一个filter的灵活配置下,使用者可以根据自己的需求来选择适合自己的架构,或者进行调整. 随手举一些例子: 选择使用nova-

OpenStack配置解析库——oslo.config

OpenStack的oslo项目旨在独立出系统中可重用的基础功能,oslo.config就是其中一个被广泛使用的库,该项工作的主要目的就是解析OpenStack中命令行(CLI)或配置文件(.conf)中的配置信息.下面先给一个high-level的过程说明一下如何使用这个库. OpenStack中配置文件的使用主要有以下几个步骤, step1. 正确配置各个服务主配置文件(.conf文件),在各个服务中完成. step2. 在要使用到配置文件的模块中声明这个模块将会用到的那些配置项(比如'au

openstack七大模块概述

前言 OpenStack主要由七部分组成,分别是Identify, Image, Network, Compute, Block Storage, Object Storage, Dashboard,分别表示认证模块,镜像模块,网络模块,计算模块,块存储模块,对象存储模块和管理模块. Identify(Keystone) 为其他几个模块提供认证服务,所有的认证操作都会通过keystone来进行. 整个keystone其实就是在数据库中建立用户(user).角色(role).Tenant.服务(s

Flume NG源代码分析(二)支持执行时动态改动配置的配置模块

在上一篇中讲了Flume NG配置模块主要的接口的类,PropertiesConfigurationProvider提供了基于properties配置文件的静态配置的能力,这篇细说一下PollingPropertiesFileConfigurationProvider提供的执行时动态改动配置并生效的能力. 要实现动态改动配置文件并生效,主要有两个待实现的功能 1. 观察配置文件是否改动 2. 假设改动,将改动的内容通知给观察者 对于第一点,监控配置文件是否改动,Flume NG定义了一个File

Ceph块设备管理与Openstack配置(上)

Oepnstack之CEPH系列是根据Ceph Cookbook整理的笔记,分为以下几个部分: <Ceph简介> <Ceph集群操作> <Ceph块设备管理与Openstack配置> <深入Ceph> <ceph优化与性能测试> 注意:此文对应ceph版本为10.1.2 #ceph -v ceph version 10.1.2(4a2a6f72640d6b74a3bbd92798bb913ed380dcd4) 前言 目前接触到的Mitaka版本O

openstack配置域名访问

#openstack配置域名访问 openstack pike 安装 目录汇总 http://www.cnblogs.com/elvi/p/7613861.html #主要是在默认配置的基础上,做了个url 301跳转 #配置域名 yun.test.com cloud.test.com echo '#openstack <VirtualHost *:80> ServerName yun.test.com ServerAlias cloud.test.com #DocumentRoot /usr

阿里微服务专家手写Spring Boot 实现一个简单的自动配置模块

为了更好的理解 Spring Boot 的 自动配置和工作原理,我们自己来实现一个简单的自动配置模块. 假设,现在项目需要一个功能,需要自动记录项目发布者的相关信息,我们如何通过 Spring Boot 的自动配置,更好的实现功能呢? 实战的开端 – Maven搭建 先创建一个Maven项目,我来手动配置下 POM 文件. 参数的配置 - 属性参数类 首先,我们定义一个自定义前缀,叫做 custom 吧.之前说到,这里的配置参数,可以通过 application.properties 中直接设置

OpenStack配置串口显示虚机界面

OpenStack配置串口显示虚机界面 OpenStack的horizon能够显示虚拟机的界面.horizon是web界面,在我们的电脑上,姑且称之为本地,虚拟机运行在远端服务器上,称之为远端.本地显示远端的界面,OpenStack提供了多种方式,noVNC 远程桌面协:RDP(Remote Desktop Protocol 远程桌面协议):SPICE (Simple Protocol for Independent Computing Environment独立计算环境简单协议).这些都是图形

ABP开发框架前后端开发系列---(12)配置模块的管理

一般来说,一个系统或多或少都会涉及到一些系统参数或者用户信息的配置,而ABP框架也提供了一套配置信息的管理模块,ABP框架的配置信息,必须提前定义好配置的各项内容,然后才能在系统中初始化或者通过接口查询来使用,本篇随笔引入了另外一种配置信息的定义,实现更加简化的处理,本篇随笔着重介绍两者之间的差异和不同的地方. 1.ABP框架的配置管理 如下面是邮件配置信息,配置信息一般先继承自SettingProvider,初始化定义后,才能被系统所使用. EmailSettingProvider:继承自Se