概览 oslo.config 是用于从命令行或配置文件解析配置参数的框架，来自于万能的 OpenStack 社区。作为 oslo 项目的子项目，可以通用在任何 python 程序中。 oslo.config 的主要特性包括： 参数的类型限定 同时管理命令行与配置文件(ini) 自动生成示例配置文件 支持参数分组 运行时重新载入配置 快速开始 安装 oslo.config pip install oslo.config 定义参数 #!/usr/bin/python # test_oslo_config.py from oslo_config import cfg from

概述 python 有大量的单元测试框架，本文尝试对下列模块进行梳理： testtools，fixture，mox，mock 本文仅从整体的角度对各模块的使用方式进行把握，更详细的信息请随时查阅文中的参考 链接。 模块列表 testtools unittest 是 python 标准库中自带的单元测试框架，python 2.7 及以后版本中为它加入一 些新特性，将这些新特性整理形成了在 python 2.6-3.4 都能工作的 unittest2 模块。 而 testtools 即是对 unittest2 的扩展。 在安装有 testtools 的 python 环境中找到文件 lib/python2.7/site-packages/

概览 setuptools 是针对 python 项目的一个打包工具，使用它可以方便地对 python 项目进行 打包安装。要使用 setuptools 只需要在安装脚本中调用其提供的 setup 方法，项目的信 息都通过高度可定制的参数传递给该方法。当调用安装脚本的时候，可以通过传递诸如 build, install 等参数直接进行构建与安装的操作。setuptools 是对 python 标准库中的 distutils 的加强。 pbr 是一个对 setuptools 加强的插件，通过它可以将 setup 函数所需的参数放在一个统 一的配置文件中集中管理，此外它也带有自动化管理项目版本的功能。pbr 来自于 openstack 社区。 快速开始 安装 setuptools 和

概览 tox 是 python 单元测试方面的工具，使用它可以方便地设定一个预期的 virtualenv 列表，并自动在每个 virtualenv 下进行指定的安装与测试工作。 tox 的使用步骤概括一下就是： 安装 tox 生成 tox 配置文件，在其中指定 virtualenv 列表以及每个 virtualenv 环境 下要运行的测试命令 由 tox 命令自动创建准备 virtualenv，并在其中运行指定的测试命令 快速开始 下面来一起试用一下 tox。 安装 tox 可以使用 pip/easy_install 来安装 tox，或者使用各 Linux 发行版的包管理器： pip

本文旨在整理字符编码的信息以及 python 对字符编码的支持情况。 what is ASCII ? 回顾一下 ASCII 码是怎么一回事。 1968 年, American Standard Code for Information Interchange 制定了一个常用字符与数字的转换关系，这个关系就以机构名称的首字母命名， 即 ASCII，ASCII 码中使用了 1-127 的数字。 ASCII 码的问题是: 127 个的数字所能代表的字符数极为有限，存在大量显示不了的字符， 例如西欧的重音符，中国汉字字符等。 1980 年的时候，大部分电脑是 8 位的，也就是能使用的数字范围为 0-255，ASCII 码使 用了其中的一半。很多不同厂商的电脑于是把 128-255定义为其它的重音符号，

routes 模块是帮助实现 url 到程序入口映射的工具，解决的问题跟 django 中 urls.py 文件里的相同。这个模块是 ruby 里 routes 模块在 python 中的重新实现。 概览 首先来看一下 routes 工作起来的样子。 from routes import Mapper map = Mapper() map.connect(None, "/error/{action}/{id}", controller="error") # Match a URL, returns a dict or None if

背景 微服务盛行的当下，服务之间的交互变得极为频繁，这带来了更好的服务模块化， 但也为开发和调试带来了一个问题，即当你正专注于解决服务 A 的问题的时候， 却常常被它的依赖服务 B 的问题搞得焦头烂额。 requests-mock 这个模块就是解决此类问题的，它通过在服务 A 中模拟所依赖的 服务 B 的 api 接口，而为服务 A 提供一致稳定的响应，从而隔离掉服务 B 所可能带来的问题。 模块地址：https://pypi.python.org/pypi/requests-mock 使用 Mocker 下面来实作一下，看几个官方的例子 以 context manager 的形式使用 Mocker >

概述 本文说一下 nova 数据库对象的远程使用。这是 nova 里很精彩的一个地方。 远程对象所实现的效果是，一个 A 服务中的远程对象实例，可以由消息队列传送到 B 服务，B 服务能够使用这个实例，当调用实例的方法时，实际执行这个方法却是在 A 服务中。 以 Instance 类的实例为例，该类是代表虚拟机数据库抽象的类，通常我们通过更改实例 的属性，并调用 Instance.save() 方法更改数据库。该类的定义在 nova/objects/instance.py 中。 nova-conductor 在收到创建虚拟机请求时生成了实例 instance = Instance()，之后将 instance 通过消息队列发送到了 nova-compute，

nova 各服务角色 先说一下 nova 各服务所担当的角色 nova-api nova-api 代表 nova 对外提供服务接口，接受虚拟机的操作指令。无论是从 openstack 的命令行还是 dashboard 界面，只要是虚拟机的 操作请求最终都会发给 nova-api 服务。这个服务通过 HTTP 协议对外提供 REST API。 nova-conductor nova-conductor 是 nova-compute 之上的一个新服务层。一者它为 nova-compute 代理数据库的操作，即 nova-compute 不直接操作数据库 而是通过 nova-conductor 的 rpc 方法来读写；二者相对于一些启动、关闭、暂停、

oslo.messaging 0x03: rpc 客户端 在前一篇 中已经提到，oslo.messaging 中的客户端实例 RPCClient 有两个方法 来完成消息的发送，它们分别是 call 和 cast。且这两个方法最终都是调用的 Transport 的 _send 方法。这一篇梳理一下这两个方法的内部实现细节。 RPCClient 回到 RPCClient 的实现。RPCClient 与 transport 之间其实还隔着一个 _CallContext 实例，但这里我们略过这一层。直接看 call 与 cast 方法的实现。 首先看一下 oslo.messaging 开发者文档所说: A

接上篇的 MessageHandlingServer 继续， 这一篇专注于梳理 oslo.messaging 中一个 rpc server 对消息的处理流程。 openstack 各服务 nova-compute, neutron-server, cinder-volume 等等每一个都对外提供了 rpc 服务，接受其它组件的 rpc 调用。例如，nova-api 接到一个创建虚拟机的请求，就是通过调用 nova-compute 的一个创建虚拟机的 rpc 接口来进行虚拟机创建的。 +------------------------+----------------+ | messaging.server.MessageHandlingServer | +------------------------------------------------+ | | +--------------------------------------------------------+ | messaging/_drivers/amqpdriver.AMQPListener | | self._executor -----------+-----&

oslo.messaging 中的 kombu 代码结构图如下： +----------------------------------------+ | | nova.rpc.get_server --> messaging.server.get_rpc_server --> | messaging.server.MessageHandlingServer | | | | self.transport | | | | +---------+------------------------------+ | v +----------------------------------------------+ +----------------------------------------+ +--------------------------+ | | | | | | | messaging._drivers.impl_rabbit.RabbitDriver | | messaging.transport.Transport | | messaging.rpc.RPCClient | <---- nova.

背景 kombu 是一个 python 消息库，提供 AMQP 协议的高级封装。 题外话：目前 kombu 也支持对非 AMQP 协议的封装，支持 Redis，MongoDB，ZeroMQ 等。 概念 参见 AMQP 协议，协议中的几个关键元素在 kombu 中都有对应的封装，下面把关系 先列出来： publisher： kombu.Producer() exchange： kombu.Exchange() queue： kombu.Queue() consumer： kombu.Consumer() 使用 建立连接 kombu 的封装抽象中建立一个连接即是建立一个

Table of Contents 安装 配置简介 配置文件 用户管理 防火墙 system limits RabbitMQ 集群 手动创建集群 重启集群 破坏集群 自动创建集群 fuel 中的 RabbitMQ 安装 rabbitmq 的安装分两部分，rabbitmq-server 自身的安装以及其依赖 erlang 的安装。 rabbitmq-server： rabbitmq-server 的安装包 fedora 系统安装源有提供，epel 也有提供。 fedora 系统源： 提供的包版本往往比较老旧，比如现在 fedora20 的源提供的版本为 3.1.5。 EPEL： 提供的版本要新得多，

简介 本文记录如果为 RabbitMQ 开启消息历史记录。基于 RabbitMQ 消息队列作应用开发的时候，难免会需要追查 RabbitMQ 服务中发送的消息详细信息。通过开启消息记录，将会为开发带来很大的便利。 打开 RabbitMQ 消息历史记录 RabbitMQ 服务自带有一个管理界面，我们只需要开启它。 打开管理插件 在安装有 RabbitMQ 服务的节点上，执行命令 rabbitmq-plugins enable rabbitmq_management。 然后重启 RabbitMQ 服务使更改生效。 这时访问本机的 15672 端口，即可看到 RabbitMQ 的管理界面： 登录管理界面，需要帐户有特殊权限，通常使用 rabbitmqctl set_user_tags administrator

问题 制作虚拟机镜像是在 openstack 外，通常都是使用镜像制作工具 image tools，或者自已动手 create image manually。然后将制作的镜像，上传至 glance 服务之中使用。 不过，在一些极为特殊的情况下，有些客户可能有特殊的需求，例如，客户想要从 windows 或者 linux iso 启动一个 openstack 虚拟机，并利用这个虚拟机制作一个镜像。这里不就需求的合理性作讨论，只说一下如何在 openstack 中达成这个需求。 面对的问题主要是两个： 如何在 openstack 中，创建包含多个磁盘的虚拟机? 因为我们基于 iso 安装虚拟机，所以除了 iso 之外，我们还需要额外传递至少一个空的磁盘给虚拟

Table of Contents 概述 模型简介 交换机 队列 绑定 消费者 消息 连接与通道 虚拟主机 协议实现 参考链接 概述 AMQP(Advanced Message Queuing Protocol)，即高级消息队列协议，是一种应用层网络协 议，它为特定客户端应用(application)与消息中间件代理(messaging middleware broker) 之间的通信提供支持。AMQP 协议有过多个版本，本文所说的是 0-9-1，针对AMQP 0-9-1 协 议模型作一个简单的介绍，该模型即 rabbitmq 所使用的模型。 模型简介 消息代理(message

问题 openstack 中 nova 对于虚拟机的操作，有非常多种，在此不一一列举。普通的操作如 start，stop，suspend，resume 是很好理解的。然而像 shelve，unshelve 就比较新颖了。 而且从官方文档中也看不出来是干嘛的，官方文档是这样说的： Shelving is useful if you have an instance that you are not using, but would like retain in your list of servers. For example, you

问题 在 Linux 下用命令行来删除文件是极为常用的操作，然后有时候会遇到文件名称为特殊字符的情况，使用普通的 rm <filename> 的方式无法对其执行删除。代表性的，像这些特殊字符： - -- ; & $ ? * \。 以如下文件为例： # ls -l total 0 -rw-r--r-- 1 apporc apporc 0 Dec 14 20:54 file -rw-r--r-- 1 apporc apporc 0 Dec 14 20:55 >file -rw-r--r-- 1

检查python setup.py –help-commands的命令列表，　会发现setuptools提供的打包命令如下: bdist create a built (binary) distribution bdist_dumb create a "dumb" built distribution bdist_rpm create an RPM distribution bdist_wininst create an executable installer for MS Windows bdist_egg create an "egg" distribution 有bdist_rpm，　可以将软件打包成rpm包，　就可以拿来方便地安装到那些使用rpm包管理机制的linux操作系