OpenStack源码探秘（二）——Oslo.config

OpenStack源码探秘（一）——Nova-Scheduler

OpenStack源码探秘（二）——Oslo.Config

最近因为一直忙于找工作和办理入职离职等相关手续，许久没有更新博客了。笔者这次换工作最后去了一家互联网公司，酷讯旅游。也是想体验一下互联网公司的文化和理念，学习一些这个领域的知识。工作内容大多是互联网应用的后台系统研发，常用语言是Python。酷讯总体上来说还是一家不错的公司，管理偏欧美风格，趋向于没有上下级的概念。希望在工作期间也能一如既往，可以留下些自己的印记。今后的业余时间，除了继续不定期的给大家带来OpenStack方面的知识分享，也会做一起互联网方向常用的Python开源项目，比如Tornado等，敬请期待。

今天给大家介绍OpenStack中负责CLI和CONF配置项解析的组件——Oslo.config。E版本前，这个功能是放在cfg模块中的，后来社区中考虑将OpenStack中共性的组件都剥离出来，统一放在Oslo模块中。今后开发新的OpenStack组件，估计都要用到Oslo模块。

下面说明一下用法：

在Oslo的cfg模块载入的时候(from Oslo.config import cfg)，会自动运行模块中的载入代码CONF = ConfigOpts()，创建一个全局的配置项管理类。

和许多Conf配置模块一样，Oslo.conf在使用时，需要先声明配置项的名称、定义类型、帮助文字、缺省值等，然后再按照事先声明的配置项，对CLI或conf中的内容进行解析。

配置项声明结构示例如下：

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

类型的定义对应Opt的各个子类。

Oslo使用register_opt方法，将配置项定义向配置项管理类configOpts的注册是在程序的运行时刻，但是必须在配置项的引用前完成。

CONF = cfg.CONF
CONF.register_opts(common_opts)

port = CONF.bind_port

使用conf.register_cli_opts()方法，配置项还可以在管理类ConfigOpts中可选注册为CLI配置项，通过程序运行的CLI参数中获得配置项取值，并在错误打印时，自动输出给CLI配置项参数的帮助文档。

conf配置文件采用的是ini风格的格式

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

    [rabbit]
    host = localhost
    port = 5672
    use_ssl = False
    userid = guest
    password = guest
    virtual_host = /

最后通过ConfigOpts类的__call()__方法，执行配置项的解析以及从CLI或配置文件读取配置项的值。

def __call__(self,
             args=None,
             project=None,
             prog=None,
             version=None,
             usage=None,
             default_config_files=None):
    """Parse command line arguments and config files.

下面是一个完整的示例

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)
CONF(default_config_files='glance.conf')
def start(server, app):
    server.start(app, CONF.bind_port, CONF.bind_host)

OpenStack项目的配置项声明和许多其他开源Python项目一样，配置项声明是放在各个调用的模块里面的。也就是说哪里用到才到哪里声明。我觉得这种方式是完全体现了Pthonic的一种声明方式，有别于其他方式，程序员在阅读程序的时候可以非常方便的在文件开头就能找到配置项的声明定义，而不用到某个指定的文件去查找，实现了KISS的原则。

PS：新公司有个tornado的生产框架，配置项声明全都放在了一个单独的python文件中，有点儿PHP的风格~最近准备优化一下。