Open liusheng opened 6 years ago
nodepool依赖于diskimage-builder来制作镜像，使用shade组件来调用OpenStack接口启动虚拟机来作为资源池（nodepool）提供给CI测试任务使用。
nodepool主要包含以下两个服务：
nodepool的配置是以yaml的形式存放在默认/etc/nodepool/nodepool.yaml的位置。
加载配置，在下述两个主要服务启动的时候，都会加载配置文件，该配置文件定义了nodepool的provider信息，以及镜像信息等。
首先根据clouds.yaml加载OpenStackclient的配置，主要包括OpenStack的认证信息，可以配置多个，具体使用哪个，在nodepool的配置文件中指定，然后初始化一个shade的client。
其次是nodepool的配置，主要包括：
nodepool-luancher服务在启动的时候会有一个死循环，在循环内部，启动多个线程来完成不同的任务。
加载provider，在加载provider以后，provider会初始化一个队列，用于存放tasks，同时会有一个死循环一直从队列中取任务来执行，提供提交task的接口用于将任务推入队列。
保证最小“ready”状态的node，会根据nodepool.yaml中配置每一种label下的虚拟机数量是否大于或等于最小个数，如果小于并且该镜像处于available状态，将创建node的请求添加到队列中。
初始化一个线程用于清理zookeeper中不存在，但是在provider中存在的虚拟机和floatingip；清理在nodepool退出以后，还处于pending状态的请求； 清理已经达到最大生存期的node
初始化一个线程用清理清理request已经丢失，或者node已经需要释放（未加锁）的node。
最后，初始化一个线程用于从请求node的队列中读取请求，调用shade创建虚拟机。
默认情况下，nodepool会启动一个webapp，监听8005端口，用于获取image list或者dib image list。
首先在服务启动之初，也是跟上述nodepool-luancher的流程调用相同的接口，加载nodepool.yaml的配置文件，用于获取镜像相关的配置。
在nodepool-builder的主流程中，主要启动三种类型的workers来完成镜像build和上传的过程：
builder 首先通过zookeeper根据时间由新到老获取镜像构建的列表，再依次遍历nodepool.yaml中配置的diskimages的信息，如果某种镜像没有构建，或者构建的时间已经超过了该种镜像所定义的“rebuild_age”（默认为1天），最后调用diskimage-builder的命令来打镜像。 也可以通过nodepool 命令手动触发镜像的build动作。开始打镜像在zookeeper中记录镜像状态为building，完成以后，在zookeeper中记录一条镜像的build记录。
uploader 首先从zookeeper中获取最近的一次镜像构建，根据镜像构建的id在镜像的build目录中检查对应的镜像是否存在，如果存在，在检查镜像是否已经上传过了，如果没有，调用OpenStack glance的镜像创建接口 上传打包好的镜像。镜像上传开始，在zookeeper中记录镜像状态为uploading，完成以后，增加一条镜像已上传的记录。
cleaner 获取每一个镜像的所有builds记录，根据时间排序，保量两条“ready”状态镜像的记录，对于这两条镜像记录，会清理掉一些上传失败，上传过程中的记录。对于其他镜像
/etc/nodepoo/nodepoo.yaml
providers
nodepool-luncher
nodepool-builder
min-ready
disk-image-create
disk-image-create -x -t qcow2 --checksum --no-tmpfs --qemu-img-options 'compat=0.10' \ -o image-name ubuntu vm simple-init'
nodepool依赖于diskimage-builder来制作镜像，使用shade组件来调用OpenStack接口启动虚拟机来作为资源池（nodepool）提供给CI测试任务使用。
nodepool主要包含以下两个服务：
nodepool配置
nodepool的配置是以yaml的形式存放在默认/etc/nodepool/nodepool.yaml的位置。
加载配置，在下述两个主要服务启动的时候，都会加载配置文件，该配置文件定义了nodepool的provider信息，以及镜像信息等。
首先根据clouds.yaml加载OpenStackclient的配置，主要包括OpenStack的认证信息，可以配置多个，具体使用哪个，在nodepool的配置文件中指定，然后初始化一个shade的client。
其次是nodepool的配置，主要包括：
nodepool-luancher
nodepool-luancher服务在启动的时候会有一个死循环，在循环内部，启动多个线程来完成不同的任务。
加载provider，在加载provider以后，provider会初始化一个队列，用于存放tasks，同时会有一个死循环一直从队列中取任务来执行，提供提交task的接口用于将任务推入队列。
保证最小“ready”状态的node，会根据nodepool.yaml中配置每一种label下的虚拟机数量是否大于或等于最小个数，如果小于并且该镜像处于available状态，将创建node的请求添加到队列中。
初始化一个线程用于清理zookeeper中不存在，但是在provider中存在的虚拟机和floatingip；清理在nodepool退出以后，还处于pending状态的请求； 清理已经达到最大生存期的node
初始化一个线程用清理清理request已经丢失，或者node已经需要释放（未加锁）的node。
最后，初始化一个线程用于从请求node的队列中读取请求，调用shade创建虚拟机。
默认情况下，nodepool会启动一个webapp，监听8005端口，用于获取image list或者dib image list。
nodepool-builder
首先在服务启动之初，也是跟上述nodepool-luancher的流程调用相同的接口，加载nodepool.yaml的配置文件，用于获取镜像相关的配置。
在nodepool-builder的主流程中，主要启动三种类型的workers来完成镜像build和上传的过程：
builder 首先通过zookeeper根据时间由新到老获取镜像构建的列表，再依次遍历nodepool.yaml中配置的diskimages的信息，如果某种镜像没有构建，或者构建的时间已经超过了该种镜像所定义的“rebuild_age”（默认为1天），最后调用diskimage-builder的命令来打镜像。 也可以通过nodepool 命令手动触发镜像的build动作。开始打镜像在zookeeper中记录镜像状态为building，完成以后，在zookeeper中记录一条镜像的build记录。
uploader 首先从zookeeper中获取最近的一次镜像构建，根据镜像构建的id在镜像的build目录中检查对应的镜像是否存在，如果存在，在检查镜像是否已经上传过了，如果没有，调用OpenStack glance的镜像创建接口 上传打包好的镜像。镜像上传开始，在zookeeper中记录镜像状态为uploading，完成以后，增加一条镜像已上传的记录。
cleaner 获取每一个镜像的所有builds记录，根据时间排序，保量两条“ready”状态镜像的记录，对于这两条镜像记录，会清理掉一些上传失败，上传过程中的记录。对于其他镜像
Q&A
/etc/nodepoo/nodepoo.yaml中的providerssection配置多个provider，只需要name区别开来即可，其他均重复。在配置完多个provider以后，重启nodepool-luncher和nodepool-builder进程以后，nodepool会分别为各个provider中定义的image信息build出来一个image，然后会使用各个provider的镜像来创建node，经过测试发现，nodepool会平均低创建node到不同的provider，只到一种镜像的node的数量满足镜像的min-ready定义的数量为止。disk-image-create的一个封装，下面是一个例子：