1 filters

根据不同的需求，有很多种类型的过滤方式，于是就有很多的filter，我们把这些filter类文件放置在同一个package中管理。当然，这些filter我们不可能全部用到，于是我们需要为管理员提供一种方式告诉系统他需要哪些filter，我们可以用配置文件实现。此外，我们需要两个额外的功能：
1. 我们想知道package中所有的filter类
2. 因为管理员可能因为疏忽大意，在配置文件中填写了错误的类（比如把过滤主机的filter填写成了其他功能的filter，因为系统中会有很多种filter，管理员也会晕头转向），对于这些错误的配置，我们需要识别，也就是所谓的容错

2 抽象

为了完成上面两个目标，我们需要一些前提。

首先，根据面向对象的原则，具有相同特征或行为的东西，需要将他们进行抽象。对于filter而言，其作用就是过滤，因此需要有一个表示过滤的基类BaseFilter。其次，过滤根据用途也分很多种，比如主机的过滤，虚拟机的过滤等等，而对于每一种过滤又有很多方法，所以某一个用途的filter也需要抽象，比如我们有BaseHostFilter表示主机过滤，它继承自BaseFilter。最后，当然是各种主机过滤的不同实现，比如基于ram的过滤，基于vcpu的过滤等等。它们的关系图如下：

因此，对于任何一种filter，我们只需调用其filter_all()方法，就能获得过滤后的结果。

3 filters管理

现在我们有了一些filter类，每个filter类分别位于单独的文件中，我们将这些文件放置在一个package中。当然，我们可能有另外一个包package2，里面是另一个功能的filters，于是我们会想到要提供一种统一的方式对这些package进行管理。

同样是面向对象的原理，我们需要一个统一的类管理这种类型的package，而不用关心每个package里到底是哪种filter（我们只知道每个package中的filters都是同一类型，即继承自同一个BaseXXXFilter，进而继承自BaseFilter）。于是，利用python的语言特性，我们可以很快的写出这样的处理类，参见nova/loadables.py中BaseLoader类的实现：

有了基类自然就有实现类。注意BaseLoader类中有一个loadable_cls_type属性，不同的实现类需要传递不同参数。比如我们有HostFilterHandler类用来管理主机过滤包中的filter类，那么就需要初始化时传递BaseHostFilter(还记得刚才的类继承图么？)。

当然，不要忘了过滤的目的，我们最好在BaseLoader类中提供一个方法get_filtered_objects(filters, objs)，调用该方法完成过滤的功能。在OpenStack中，该方法是在一个继承自BaseLoader类，同时又被HostFilterHandler类继承的类(BaseFilterHandler)中实现。即：

4 代码

以创建虚拟机调度为例，在nova-scheduler中有HostManager类，其功能主要是管理主机，当然也包括对主机进行过滤。在其初始化函数中有以下两句：

其中：
1. HostFilterHandler：filter管理类，位于nova/scheduler/filters/__init__.py，而nova/scheduler/filters/路径下就是主机过滤的类文件，它的初始化可以验证上面的理论。

2. 配置项scheduler_available_filters：
表示管理员希望使用哪些filters。为了容错，我们调用get_matching_classes方法来排除因管理员疏忽而填错的类。

在HostManager类的get_filtered_hosts方法中完成对主机的过滤：

即：对hosts表示的每一个主机，调用filter_classes表示的每个filter处理，返回通过的hosts。

具体的过滤方式是：
假如管理员配置了filter1, filter2, filter3，有三个主机host1, host2, host3。于是按照filter的顺序，假如host1和host3通过了filter1，那么调用filter2时，只考虑host1和host3。假如只有host1通过了filter2，则调用filter3时，仅考虑host1。

本博客欢迎转发，但请保留原作者信息（@孔令贤HW）！内容系本人学习、研究和总结，如有雷同，实属荣幸！