共计 3826 个字符，预计需要花费 10 分钟才能阅读完成。
这篇文章主要介绍 OpenStack 如何处理 BUG，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！
一. 发现 Bug:
?Nova 中的虚拟机软删除 (soft-delete) 功能，是指在一段时间内，仅将数据库中的某虚拟机记录做一个标记 (status= SOFT-DELETE)，然后将虚拟化平台(kvm 等) 中对应的虚拟机实例置为关机状态，当超过某一时间段后才将虚拟机实例真正删除; 该功能为云平台用户提供了“后悔时间”，可以在一定程度上挽回误操作。默认情况下，软删除功能是关闭的，其开启方式是在 nova 配置文件中添加 reclaim_instance_interval 选项，并将其值设置为 后悔时间 的毫秒数。
?在描述具体 Bug 前，需要对 openstack 中的用户管理方面的基本概念简单介绍一下。
?上图是 openstack 用户模型的简化版本，为了便于理解将不属于 keystone 管理的 quota 也拿了过来。
?Bug 就与软删除相关。具体场景是这样的：假设 OpenStack 中有两个项目和两个用户: 普通项目 A 其用户 a, 管理员项目 Admin 其用户为 admin(用户管理相关概念可以查阅 keystone 文档)，用户 a 不慎将自己的一台虚拟机删除了，这时求助系统管理员看看有没有办法恢复，好在系统开启的软删除功能，而且被删除的虚拟机还在可回收的时间范围内，这时管理员便以 admin 的身份登录系统，为用户 a 恢复了虚拟机，但是细心的管理员却发现了一些不对：其 Admin 项目下并没有任何虚拟机，但是其配额却被使用了，难道这和刚才的操作有关？再来重试一下：普通用户删除虚拟机，admin 用户来为其恢复，这时配额又发生了变化，果然如此：被恢复的虚拟机的配额错误的添加到了 Admin 项目下。该 Bug 在最新的 kilo 版本中仍然存在，感兴趣的同学可以实验一下。
二. 定位 Bug:
?发现了 Bug 的存在，那就更进一步，到代码中找一下原因吧。
?如何确定问题代码的位置呢？这需要对 Nova 的项目结构有大体的了解，我们来简单了解一下：
?上图是 nova 架构的极简版本，与本问题无关的组件都没有画上去，恢复虚拟机的操作过程大致是这样：
nova api 接收到用户请求，到数据库中查询虚拟机详情，将该虚拟机所在的主机、名称等数据发送到消息队列中;
nova compute 服务在监听到相关消息后，开始执行具体操作，将虚拟机在数据库中的记录做些调整，调用底层驱动恢复虚拟机。
?既然软删除的功能层面没有任何问题，虚拟机的删除和恢复过程都很顺利，可见不会是驱动的问题，顺着 API 层的代码调用往下找，很快就可以定位了。直接看出问题的代码片段：
def restore(self, context, instance):
# 该代码做了删减
flavor = instance.get_flavor()
# 获取 quotas 对象
num_instances, quotas = self._check_num_instances_quota( context, flavor, 1, 1)
self._record_action_start(context, instance, instance_actions.RESTORE)
try:
if instance.host:
instance.task_state = task_states.RESTORING
instance.deleted_at = None
instance.save(expected_task_state=[None])
self.compute_rpcapi.restore_instance(context, instance)
else:
instance.vm_state = vm_states.ACTIVE
instance.task_state = None
instance.deleted_at = None
instance.save(expected_task_state=[None])
# 更新 quotas
quotas.commit()?上面的这段代码就是 API 层面上进行虚拟机回收的主要方法，可以看到其中有明显的配额操作(quotas)，在解读这段代码前有必要先对 nova 中 context 的概念做个简介。不仅是 nova，在 openstack 其他项目中都随处可见这个 context，它是一个包装了用户请求信息的对象，包含用户的项目和认证信息等，通过它可以简便的进行各项目之间的 API 调用和用户信息的查询，API 服务接收到用户的每一次 HTTP 请求，都会创建一个新的 context。
?回到这段代码，我们重点关注对 quotas 所作的操作：在方法的第二行，通过了一个方法获取了 quotas，有在方法的结尾执行了 quotas.commit()，能够获取到的信息不多，我们再看一下获取 quotas 的方法：_check_num_instances_quota
# 这里只截取一部分
def _check_num_instances_quota(self, context, instance_type, min_count,
max_count):
req_cores = max_count * instance_type[vcpus]
vram_mb = int(instance_type.get( extra_specs , {}).get(VIDEO_RAM, 0))
req_ram = max_count * (instance_type[ memory_mb] + vram_mb)
try:
quotas = objects.Quotas(context)
quotas.reserve(context, instances=max_count,
cores=req_cores, ram=req_ram)
...
return max_count, quotas?这里可以看到获取 quotas 的过程：通过当前的 context 创建 quotas 对象，并且执行了 reserve 操作; 我们知道 context 是由 HTTP 请求而来，里面保存的是发请求的用户的信息，所以这里的 quotas 对象的“所有者”也就是 context 中的用户。
?结合 Bug 发生的场景来看：管理员还原用户 a 的虚拟机，发请求的是管理员，当前 context 中记录的是管理员的信息，这里的 quotas 理所当然的就是管理员的，然后操作了用户 a 的虚拟机，更新的却是管理员的 quotas。嗯，真相大白！
三. 修复 Bug:
?Bug 的原因是获取的 quotas 并不属于期望的用户，但是直接修改 context 显然不合适(会影响后续的操作)，先了解一下 quotas 对象自身吧：
class Quotas(base.NovaObject):
# 部分代码
def __init__(self, *args, **kwargs):
super(Quotas, self).__init__(*args, **kwargs)
# Set up defaults.
self.reservations = []
self.project_id = None
self.user_id = None
self.obj_reset_changes()
...
def reserve(self, context, expire=None, project_id=None, user_id=None,
**deltas):
reservations = quota.QUOTAS.reserve(context, expire=expire,
project_id=project_id,
user_id=user_id,
**deltas)
self.reservations = reservations
self.project_id = project_id
self.user_id = user_id
self.obj_reset_changes()
def commit(self, context=None):
if not self.reservations:
return
if context is None:
context = self._context
quota.QUOTAS.commit(context, self.reservations,
project_id=self.project_id,
user_id=self.user_id)
self.reservations = None
self.obj_reset_changes()?注意看 reserve 方法的参数，默认为 None 的 project_id 和 user_id，这正是改变 quotas 属主的方便入口！
?修改后的代码这里就不贴了，感兴趣的同学可以到这次提交中看：Code Review
四. 代码提交和 Review:
?openstack 社区有着整套项目管理流程，这里有一张图能够较详细的描述工作流程：
?由图可见 bugfix 是其中最简单的流程。
以上是“OpenStack 如何处理 BUG”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注丸趣 TV 行业资讯频道！
