本次培训的内容分为三个部分:第一,介绍OpenStack公共基础库Oslo的整体情况;第二,关键组件分析;第三,近期版本功能更新。

 

 

在开始之前我想问大家一个问题,OpenStack到底有多少个项目?目前OpenStack官方认可的项目有60个,代码仓库有988个,项目跟代码仓库是1和0的关系。

 

有这么多的项目和代码仓库,随之而来就有一个问题——每个人专注的项目可能只是其中一个,但是这个项目会有一些通用的功能,如配置项目管理、数据库访问和项目队列服务。因此,我们认为需要一个专门的团队来提供公共代码。


左下是两个项目的代码结构。左边是三个方块跟一个三角形,右边是三个圆加一个三角形。三角形表示同样的代码。我们希望可以共同维护这个公共的部分,所以OpenStack需要一个基础库。简单理解就是用基础库为各种开发提供一些公共的函数,方便使用。

 

简单介绍一下Oslo的历史。这个项目的官方名字是OpenStack Common Libraries。该项目的使命总结为:提供一系列包含共享代码的python库为其他项目使用。这些库提供的API是高质量的、稳定的、一致性的、文档化的,并且通常具有可应用性。这个项目最早是因为我们发现很多时候可以共享代码,所以建立oslo-incubator,把大家的代码放在这里,如果要用的话就拷贝过去。

 

到2016年1月,我们有了第一个独立的库,之后这些库就都独立出来。这时候oslo-incubator完成了它的使命,现在不建议大家再去用它。我们还在不断地吸引一些新的项目,包括castellan。

 

OpenStack Oslo有很多的项目或者说库,但是其应用从使用人群或者用户来分可以分为三类:第一类是OpenStack开发者会用到的如数据库访问、消息队列、服务方式运行、常用方法等;第二类是与OpenStack运维人员有很大关系的。如通过改变一个配置项就可以影响OpenStack运行行为的配置项管理,在通过配置项授权之后的用户访问权限设置,以及寻找OpenStack运行速度减慢的瓶颈即通过请求时间收集操作时间和运行时状态检查来查看整个OpenStack的运行情况;第三类是Oslo与其它项目不太一样的地方,Python应用者可以将常见的数据访问、配置项管理用于非OpenStack的开发。我们公司内部正在搭建的一个框架就使用了Oslo的一些组件库。

 

Oslo有35个项目,其中castellan是通用的,cookiecutter通过一条命令帮助创建一个项目的代码结构和目录,osprofiler是管理,最下面的stevedore是一个插件集成方式。所有这些信息都可以通过页面下面的网站(https://wiki.openstack.org/wiki/Oslo)去访问。

 

下面介绍一下关键组件的分析。

 

第一个oslo.config,它的用途是分析命令行或文件里的配置选项。每一个常用类型都可以有一些限制条件,比如IntOpt类型可以用最大最小值,如果配置了一个负值或者超零范围,启动时就有问题。

我们看一个具体的例子。第一步是从EasyStack.config里面import这个库,第二步是申领一些import类型,后面有一个注册,写代码就是最下面的,直接就可以用了。这是最典型的用法,在oslo.config里面有一些常用的事项,如果想用一个常用的值,需要在默认值里面把决定A的值可以去决定B的值。

另外,可以决定一些好的技术条件,比如配置项只允许三种类型ABC,如果配置D的话是不允许的,而且不希望在问题出现的时候才发现这个问题,需要在一开始就知道。

 

第二个比较重要的是对数据库的访问,其用途是访问关系型数据库。支持多种数据库,如MySQL、PostgreSQL、DB2,不支持MongoDB,依赖底层SqlAchemy。这里分为几个层,中间是第三方API,上面是一些核心。使用MongoDB的时候一定要对SqlAchemy有些了解才能用。

 

大家可以看,实际上就是两个函数。右边对一张表的结构进行了分类。这些东西准备好了,照着这个规范去写就可以把细节屏蔽掉。

 

接下来,介绍一个比较通用的项目是效率队列。做过OpenStack的人都知道效率队列是很重要的,如果效率队列出现问题那就除了简单地查询数据库,别的基本上没法操作。

举个例子,它提供了两种用途,一种是RPC,可以理解为远程调用,是一个同步过程,需要反馈结果。还有一种是notification,OpenStack有一个项目可以收集这种notification的。Oslo.messaging本身支持多种driver,amqp、fake、Kafka、rabbit(kombu)、zmq。

 

这个想法是它的上层提供一个接近用户编程习惯或者用户友好的概念,屏蔽了底层的多种理解方式,用户只要理解上面的一些概率就可以了

 

其余transport指的是底层消息队列到底采用哪一种。executors是接受消息之后怎么处理,是指新请求在后面排队,还是说再起一个线程处理。target是消息发到哪。server是指处理端,RPC Client是指请求的客户端。

这是一个代码,基本上定义了刚才我说的几个概念。这个test一定是在上面第二类,这就是整个oslo.messaging的一个用法。

 

第三部分分析一下近期版本的功能更新。我们现在正在开发的是tag版本。

Oslo.policy更新。刚才说用户想要做一个请求的时候需要验证他是否有权限,比如有些操作只能是专员操作,普通用户不允许,所以oslo.policy进行检验API授权,可以理解为到policy文件里面去读取这些规则,右侧是json,每一条相当于规则。


大家看这个图可能会发现一些问题——如果不是开发者,是不知道这个代表什么意思的,不去读代码是没有办法知道到底有多少policy可以涉及或者不可以涉及的,所以部署者必须设定所有的规则。而规则特别多,都需要手工去点,要是开发者把这些规则放到代码里去就好了。

另外,我们从代码里面没法获取规则,所以我们添加了改进方式——增加了注册policy规则,在代码里面可以注册这个规则,不用都写在上头。另外可以从代码上面添加自动生成policy规则,允许policy规则传入帮助文字及生成。希望所有的运维人员只要看到这个原文件就可以自动识别,这是从可管理性方面的一些改进。

 

Oslo.config的更新。其实这不是什么创新,因为大家都有这种需求:在跑程序的时候希望改变它的状态,而不是说把这个service停了。典型的用法是我们在发现一个问题的时候想把logging改掉,但是在写程序的时候就没了。那么可以通过改变配置项把这个logging更改。另外就是机器可读格式,Oslo.config可以生成ini格式的sample配置文件,这些程序可以通过读取去替换配置项值。


另外开发出的一个新功能叫validator,解决的问题是已有的配置项是不是有些配置错了,或者这个配置项是不是已经废弃了但还在用。还有随着容器崛起,有一些好的组件出现,如etcd是重组plugin值的,而且这个值不需要存在文件里。

 

最后介绍一下与运维人员特别相关的一部分。对于查找问题特别好的Global request id。它能解决什么问题?我们在记录OpenStack的时候,比如创建一个虚机的时候,每个组件会对应一个request id,不同的组件有不同的request id。但是我们目前的比对是查找,希望每个操作都可以用一个request id来表示,这样做的效果是运维的时候我们可以通过检索机制,把相关的log都抓取出来。目前这项工作已经基本快做完了,部分正在做收尾工作,由多个组件进行改变。

另外一个就是接收castellan项目,这个项目的全称是generic key mananger inter face for OpenStack。我希望Barbican与Oslo团队共同维护,Barbican是Castellan drive的工具。

 


总体来说,Oslo目前的情况是,一方面核心功能模块功能稳定,在做一些局部的优化,而且更多是从为用户或者运维人员度提供方便的角去做。另一方面是适应新需求开发新的功能,包括我刚才介绍的一些功能。

展望未来,Oslo项目非常关键,每个项目如果出了问题其实是影响各个组件的,所以我们需要积累更多的Oslo开发者,推广Oslo的应用。这里指的不仅仅是OpenStack格式,而是开发其他开源程序也可以用Oslo,并经过成果检验。

另外需要加强文档编写,我个人如果时间允许的话可能会写一本专门介绍Oslo的书。

这就是今天我跟大家分享的内容,谢谢大家!

投稿邮箱:opensta