Tripleo之nova-compute 和Ironic的代码深入分析(一)

声明：

本博客欢迎转载，但请保留原作者信息!

作者：姜飞

团队：华为杭州OpenStack团队

我们大家都知道部署物理机跟部署虚拟机的概念在nova来看是一样，都是nova通过创建虚拟机的方式来触发，只是底层nova-scheduler和nova-compute的驱动不一样。虚拟机的底层驱动采用的libvirt的虚拟化技术，而物理机是采用PXE+IPMItool的方式，当让PXE+ipmitool只是其中一种比较常用的技术，其他的方式也可以实现，像开发环境部比较少的话，也可以使用PXE+SSH的方式，我就是采用这种方式实践的。

采用官方的一个图，可以大致了解他的框架和流程是怎么走的，详情请见官方文档：http://docs.openstack.org/developer/ironic/deploy/user-guide.html

好了，废话少说，那我们就一起来看看相关的代码分析：

 

配置

在/etc/nova/nova.conf的配置文件中修改manager和driver

Vi /etc/nova/nova.conf

[DEFAULT]
scheduler_host_manager = nova.scheduler.ironic_host_manager.IronicHostManager
compute_driver = nova.virt.ironic.driver.IronicDriver
compute_manager = ironic.nova.compute.manager.ClusteredComputeManager
[ironic]
admin_username = ironic
admin_password = unset
admin_url = http://127.0.0.1:35357/v2.0
admin_tenant_name = service

nova-scheduler的mamager是：
scheduler_host_manager = nova.scheduler.ironic_host_manager.IronicHostManager

nova-compute的manager和driver是：

compute_driver =nova.virt.ironic.driver.IronicDriver

compute_manager = ironic.nova.compute.manager.ClusteredComputeManager

 

其中compute_manager的代码实现是在ironic项目里面。 

创建虚拟机的流程就不描述了，nova-api接收到nova boot的请求，nova-scheduler收到请求后，在scheduler_host_manager里面处理：

Nova-scheduler会使用flavor里面的额外属性extra_specs，像cpu_arch，baremetal:deploy_kernel_id，baremetal:deploy_ramdisk_id等过滤条件找到相匹配的物理节点。

Nova-compute

Nova-compute在启动的时候会初始化nova.service.py的Service类，调用launch方法将nova-compute的进程拉起来，最终调用到Service类的start方法：

    def start(self):
        verstr = version.version_string_with_package()
        LOG.audit(_('Starting %(topic)s node (version %(version)s)'),
                  {'topic': self.topic, 'version': verstr})
        self.basic_config_check()
        self.manager.init_host()  # compute-manager的初始化
        self.model_disconnected = False
        ctxt = context.get_admin_context()
		…….
		#compute_manager的pre_start_hook方法
        self.manager.pre_start_hook()
        …..

那么这个self.manager是哪里定义的呢，

nova.compute的main函数：

   server = service.Service.create(binary='nova-compute',

                                   topic=CONF.compute_topic,

                                   db_allowed=CONF.conductor.use_local)

nova.service的create方法：

    def create(cls, host=None, binary=None, topic=None, manager=None,
               report_interval=None, periodic_enable=None,
               periodic_fuzzy_delay=None, periodic_interval_max=None,
               db_allowed=True):
        #这里的binary就是nova-compute，manager_cls就是compute-manger，manager就是获取的compute-manager的配置项。
        if not manager:
            manager_cls = ('%s_manager' %
                           binary.rpartition('nova-')[2]) 
            manager = CONF.get(manager_cls, None)
			……
        service_obj = cls(host, binary, topic, manager,
                          report_interval=report_interval,
                          periodic_enable=periodic_enable,
                          periodic_fuzzy_delay=periodic_fuzzy_delay,
                          periodic_interval_max=periodic_interval_max,
                          db_allowed=db_allowed)

而self.manager的初始化是在Services的初始化方法：

def __init__(self, host, binary, topic, manager, report_interval=None,
                 periodic_enable=None, periodic_fuzzy_delay=None,
                 periodic_interval_max=None, db_allowed=True,
                 *args, **kwargs):
        super(Service, self).__init__()
        self.host = host
        self.binary = binary
        self.topic = topic
        self.manager_class_name = manager
        self.servicegroup_api = servicegroup.API(db_allowed=db_allowed)
        manager_class = importutils.import_class(self.manager_class_name)
        self.manager = manager_class(host=self.host, *args, **kwargs)

self.manager.init_host()调用的是compute-manager的init-host方法，我们配置文件里面写的是ironic.nova.compute.manager.ClusteredComputeManager， 所以调用到了compute-manager的init-host方法。

class ClusteredComputeManager(manager.ComputeManager):

    def init_host(self):
        """Initialization for a clustered compute service."""
        #调用compute_driver的init_host方法，当前没有做什么事情
        self.driver.init_host(host=self.host) 
      	
        #调用父类的init_virt_events方法
        self.init_virt_events()

compute-manager的init-host方法的第一步调用self.driver.init_host(host=self.host)，这里的self.dirver是什么呢？ 其实就是我们在配置文件里面写的compute-driver。

 

我们来看下self.dirver是怎么定义的：

ClusteredComputeManager的父类是nova.compute.manager.ComputeManager的初始化方法__init__方法：

def __init__(self, compute_driver=None, *args, **kwargs):
        """Load configuration options and connect to the hypervisor."""
        self.virtapi = ComputeVirtAPI(self)
        self.network_api = network.API()
        self.volume_api = volume.API()
        self.image_api = image.API()
        self._last_host_check = 0
		…….
        self.driver = driver.load_compute_driver(self.virtapi, compute_driver)

而load_compute_driver做的事情就是加载相关的driver

def load_compute_driver(virtapi, compute_driver=None):
    if not compute_driver:
    	compute_driver = CONF.compute_driver

    if not compute_driver:
        LOG.error(_("Compute driver option required, but not specified"))
        sys.exit(1)

    LOG.info(_("Loading compute driver '%s'") % compute_driver)
    try:
        driver = importutils.import_object_ns('nova.virt',
                                              compute_driver,
                                              virtapi)
        return utils.check_isinstance(driver, ComputeDriver)
    except ImportError:
        LOG.exception(_("Unable to load the virtualization driver"))
        sys.exit(1)

细心的同学应该注意到，为什么self.manager = manager_class(host=self.host, *args, **kwargs)调用的是host=self.host，到了ClusteredComputeManager的初始化方法却是compute_driver=None， 其实这个就是可选参数， 在load_compute_driver方法里面，假如compute_driver为None，则设置compute_driver= CONF.compute_driver，所以self.driver就是compute_driver的配置项设置的值。

OK，回到刚才self.manager的init_host方法，self.driver.init_host(host=self.host)调用的是nova.virt.ironic.driver.IronicDriver的init_host方法，当前Juno版本的init_host方法啥事情都没有做。父类的init_virt_events方法调用slef.driver的register_event_listener方法，但是self.driver没实现这个方法，所以需要到dirvier的父virt_driver.ComputeDriver，将self.handle_events作为self._compute_event_callback的回调函数，这个回调函数是接收从libvirtd的异步事件消息。

    def init_virt_events(self):
        self.driver.register_event_listener(self.handle_events)

回到Service类的start方法，往下的话就是判断nova-compute的service是否存在，这些就省略不写，跟nova-compute的流程是一样的。

接着看self.manager.pre_start_hook()， 这个Ironic的manager类ClusteredComputeManager是有实现的：

    def pre_start_hook(self):
        try:
            self.update_available_resource(nova.context.get_admin_context())
        except Exception:
            pass

self.update_available_resource的是父类nova.compute.manage.ComputeManager的方法：

update_available_resource这个是个周期任务，这方法主要就是把ironic所有的node节点的信息都同步到compute_node中去，nova-scheduler在走过滤器的时候才能根据过滤条件找到适合的物理主机。

    @periodic_task.periodic_task
    def update_available_resource(self, context):
        """See driver.get_available_resource()

        Periodic process that keeps that the compute host's understanding of
        resource availability and usage in sync with the underlying hypervisor.

        :param context: security context
        """
        new_resource_tracker_dict = {}

        nodenames = set(self.driver.get_available_nodes())
        for nodename in nodenames:
            rt = self._get_resource_tracker(nodename)
            rt.update_available_resource(context)
            new_resource_tracker_dict[nodename] = rt

        # Delete orphan compute node not reported by driver but still in db
        compute_nodes_in_db = self._get_compute_nodes_in_db(context,
                                                            use_slave=True)

        for cn in compute_nodes_in_db:
            if cn.hypervisor_hostname not in nodenames:
                LOG.audit(_("Deleting orphan compute node %s") % cn.id)
                cn.destroy()

        self._resource_tracker_dict = new_resource_tracker_dict

self.driver的get_available_nodes获取ironic的所有注册的node节点，方法_refresh_cache()内部维护了一个self.node_cache= {}的一个dict，从ironic的api接口ironic node-list查询出所有的node节点，放在缓存中, 如果该节点存在的话，则调用resource_tracker.ResourceTracker生成一个新的rt对象，缓存到self._resource_tracker_dict中,返回这个rt对象。然后执行rt.update_available_resource()， 在nova.compute.resource_tracker.ResourceTracker类中。

rt.update_available_resource()是先从node-cache中找到该节点信息，如果没有，则从ironic-api中调用ironic接口查询，比较关键的是最后一个动作self._node_resource(node)， 这个动作会做了一些逻辑判断，CPU类型转化等。

    def get_available_resource(self, nodename):
        …….
        return self._node_resource(node)

    def _node_resource(self, node):
        """Helper method to create resource dict from node stats."""
        vcpus = int(node.properties.get('cpus', 0))
        memory_mb = int(node.properties.get('memory_mb', 0))
        local_gb = int(node.properties.get('local_gb', 0))
        raw_cpu_arch = node.properties.get('cpu_arch', None)
        try:
            #将amd64转化为X86-64，其他的类型会转化I686，或者不存在
            cpu_arch = arch.canonicalize(raw_cpu_arch)
        except exception.InvalidArchitectureName:
            cpu_arch = None
        if not cpu_arch:
            LOG.warn(_LW("cpu_arch not defined for node '%s'"), node.uuid)

        nodes_extra_specs = {}
        nodes_extra_specs['cpu_arch'] = raw_cpu_arch
        …..
        if node.instance_uuid:
            # Node has an instance, report all resource as unavailable
            vcpus_used = vcpus
            memory_mb_used = memory_mb
            local_gb_used = local_gb
        elif self._node_resources_unavailable(node):
        #假如单板的power-state在[ironic_states.ERROR, ironic_states.NOSTATE] 或者属于维护状态，则不上报该单板的资源。
            vcpus = 0
            memory_mb = 0
            local_gb = 0
		……
        dic.update(nodes_extra_specs)
        return dic

这里跟虚拟机的driver不同主要是在hypervisor_type 是ironic ，cpu_info是” baremetal cpu”,其他地方都是大同小异，没有什么不同。

Nova-compute走完self.manager.pre_start_hook()这个步骤，后面的步骤跟虚拟机的启动完全都是一样的了，创建rabbitmq的消息队列等等，这里就不在描述，详见nova-compute的流程，tripleo就不在这里描述了。