在改章节中,我们主要分析配置项声明的内容,自我感觉有个不错的建议和大家分享下
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的注册是在程序的运行时刻，但是必须在配置项的引用前实现。
每日一道理
当浮华给予我们过多欺骗，现实中的虚假几乎让我们忘却了真的存在，是真情唤回了迷离的心，是真情带给了我们最纯、最真的感觉，它流露的是美的誓言，渗透的是永恒执著的真爱。