部署物理机跟部署虚拟机的概念在nova来看是一样,都是nova通过创建虚拟机的方式来触发,只是底层nova-scheduler和nova-compute的驱动不一样。虚拟机的底层驱动采用的libvirt的虚拟化技术,而物理机是采用Ironic技术,ironic可以看成一组Hypervisor API的集合,其功能与libvirt类似。
操作系统安装过程
Linux系统启动过程
- bootloader(引导程序,常见的有GRUB、LILO)
- kernel(内核)
- ramdisk(虚拟内存盘)
- initrd/initramfs (初始化内存磁盘镜像)
下面我们分别介绍每个概念:
- 引导加载程序是系统加电后运行的第一段软件代码。PC机中的引导加载程序由BIOS(其本质就是一段固件程序)和位于硬盘MBR(主引导记录,通常位于第一块硬盘的第一个扇区)中的OS BootLoader(比如,LILO和GRUB等)一起组成。BIOS在完成硬件检测和资源分配后,硬盘MBR中的BootLoader读到系统的RAM中,然后控制权交给OS BootLoader。
- bootloader负责将kernel和ramdisk从硬盘读到内存中,然后跳转到内核的入口去运行。
- kernel是Linux的内核,包含最基本的程序。
- ramdisk是一种基于内存的虚拟文件系统,就好像你又有一个硬盘,你可以对它上面的文件添加修改删除等等操作。但是一掉电,就什么也没有了,无法保存。一般驱动程序放在这里面。
- initrd是boot loader initialized RAM disk, 顾名思义,是在系统初始化引导时候用的ramdisk。也就是由启动加载器所初始化的RamDisk设备,它的作用是完善内核的模块机制,让内核的初始化流程更具弹性;内核以及initrd,都由 bootloader在机子启动后被加载至内存的指定位置,主要功能为按需加载模块以及按需改变根文件系统。initramfs与initrd功能类似,是initrd的改进版本,改进了initrd大小不可变等等缺点。
为什么需要initrd?
在早期的Linux系统中,一般就只有软盘或者硬盘被用来作为Linux的根文件系统,因此很容易把这些设备的驱动程序集成到内核中。但是现在根文件系统 可能保存在各种存储设备上,包括SCSI, SATA, U盘等等。因此把这些设备驱动程序全部编译到内核中显得不太方便,违背了“内核”的精神。在Linux内核模块自动加载机制中可以利用udevd可以实现内核模块的自动加载,因此我们希望根文件系统的设备驱动程序也能够实现自动加载。但是这里有一个矛盾,udevd是一个可执行文件,在根文件系统被挂载前,是不可能执行udevd的,但是如果udevd没有启动,那就无法自动加载根根据系统设备的驱动程序,同时也无法在/dev目录下建立相应的设备节点。
为了解决这个矛盾,于是出现了initrd(boot loader initialized RAM disk)。initrd是一个被压缩过的小型根目录,这个目录中包含了启动阶段中必须的驱动模块,可执行文件和启动脚本。包括上面提到的udevd,当系统启动的时候,bootload会把内核和initrd文件读到内存中,然后把initrd的起始地址告诉内核。内核在运行过程中会解压initrd,然后把initrd挂载为根目录,然后执行根目录中的/initrc脚本,可以在这个脚本中运行initrd中的udevd,让它来自动加载设备驱动程序以及 在/dev目录下建立必要的设备节点。在udevd自动加载磁盘驱动程序之后,就可以mount真正的根目录,并切换到这个根目录中。
Linux启动一定要用initrd么?
如果把需要的功能全都编译到内核中(非模块方式),只需要一个内核文件即可。initrd 能够减小启动内核的体积并增加灵活性,如果你的内核以模块方式支持某种文件系统(例如ext3, UFS),而启动阶段的驱动模块放在这些文件系统上,内核是无法读取文件系统的,从而只能通过initrd的虚拟文件系统来装载这些模块。这里有些人会问: 既然内核此时不能读取文件系统,那内核的文件是怎么装入内存中的呢?答案很简单,Grub是file-system sensitive的,能够识别常见的文件系统。通用安装流程如下:
- 开机启动,BIOS完成硬件检测和资源分配,选择操作系统的启动(安装)模式(此时,内存是空白的)
- 然后根据相关的安装模式,寻找操作系统的引导程序(bootloader)(不同的模式,对应不同的引导程序当然也对应着不同的引导程序存在的位置)
- 引导程序加载文件系统初始化(initrd)程序和内核初始镜像(vmlinuz),完成操作系统安装前的初始化
- 操作系统开始安装相关的系统和应用程序。
PXE部署过程
PXE协议分为client和server两端,PXE client在网卡的ROM中,当计算机启动时,BIOS把PXE client调入内存执行,并显示出命令菜单,经用户选择后,PXE client将放置在远端的操作系统通过网络下载到本地运行。
安装流程如下:
- 客户机从自己的PXE网卡启动,向本网络中的DHCP服务器索取IP,并搜寻引导文件的位置
- DHCP服务器返回分给客户机IP以及NBP(Network Bootstrap Program )文件的放置位置(该文件一般是放在一台TFTP服务器上)
- 客户机向本网络中的TFTP服务器索取NBP
- 客户机取得NBP后之执行该文件
- 根据NBP的执行结果,通过TFTP服务器加载内核和文件系统
- 安装操作系统
流程小结:
客户端广播dhcp请求——服务器相应请求,建立链接——由dhcp和tftp配置得到ip还有引导程序所在地点——客户端下载引导程序并开始运行——引导程序读取系统镜像-安装操作系统
相关文件位置与内容:
- dhcp配置文件/etc/dhcpd/dhcp.conf——ip管理与引导程序名称
- tftp配置文件/etc/xinetd.d/tftp——tftp根目录,和上面的引导程序名称组成完整路径
- 引导程序读取的配置文件/tftpboot/pxelinux.cfg/default——启动内核其他
参考资料: PXE网络安装操作系统过程
Ironic部署过程
部署流程
此图是Liberty版的官方裸机部署过程图,部署过程描述如下:
- 部署物理机的请求通过 Nova API 进入Nova;
- Nova Scheduler 根据请求参数中的信息(指定的镜像和硬件模板等)选择合适的物理节点;
- Nova 创建一个 spawn 任务,并调用 Ironic API 部署物理节点,Ironic 将此次任务中所需要的硬件资源保留,并更新数据库;
- Ironic 与 OpenStack 的其他服务交互,从 Glance 服务获取部署物理节点所需的镜像资源,并调用 Neutron 服务为物理机创建网路端口;
- Ironic 开始部署物理节点,PXE driver 准备 tftp bootloader,IPMI driver 设置物理机启动模式并将机器上电;
- 物理机启动后,通过 DHCP 获得 Ironic Conductor 的地址并尝试通过 tftp 协议从 Conductor 获取镜像,Conductor 将部署镜像部署到物理节点上后,通过 iSCSI 协议将物理节点的硬盘暴露出来,随后写入用户镜像,成功部署用户镜像后,物理节点的部署就完成了。
下面我们通过代码来分析Ironic的部署流程。
Ironic给物理机部署系统详解
配置
在/etc/nova/nova.conf中修改manager和driver,比如修改成如下:
[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
compute_manager的代码实现是在ironic项目里面。
部署流程
第一步, nova-api接收到nova boot的请求,通过消息队列到达nova-scheduler
第二步, nova-scheduler收到请求后,在scheduler_host_manager里面处理。nova-scheduler会使用flavor里面的额外属性extra_specs,像cpu_arch,baremetal:deploy_kernel_id,baremetal:deploy_ramdisk_id等过滤条件找到相匹配的物理节点,然后发送RPC消息到nova-computer。
第三步,nova-computer拿到消息调用指定的driver的spawn方法进行部署,即调用nova.virt.ironic.driver.IronicDriver.spawn(), 该方法做了什么操作呢?我们来对代码进行分析(下面的代码只保留了主要的调用)。
def spawn(self, context, instance, image_meta, injected_files,
admin_password, network_info=None, block_device_info=None):
#获取镜像信息 image_meta = objects.ImageMeta.from_dict(image_meta) ...... #调用ironic的node.get方法查询node的详细信息,锁定物理机,获取该物理机的套餐信息 node = self.ironicclient.call("node.get", node_uuid) flavor = instance.flavor #将套餐里面的baremetal:deploy_kernel_id和baremetal:deploy_ramdisk_id信息 #更新到driver_info,将image_source、root_gb、swap_mb、ephemeral_gb、 #ephemeral_format、preserve_ephemeral信息更新到instance_info中, #然后将driver_info和instance_info更新到ironic的node节点对应的属性上。 self._add_driver_fields(node, instance, image_meta, flavor) ....... # 验证是否可以部署,只有当deply和power都准备好了才能部署 validate_chk = self.ironicclient.call("node.validate", node_uuid) ..... # 准备部署 try: #将节点的虚拟网络接口和物理网络接口连接起来并调用ironic API #进行更新,以便neutron可以连接 self._plug_vifs(node, instance, network_info) self._start_firewall(instance, network_info) except Exception: .... # 配置驱动 onfigdrive_value = self._generate_configdrive( instance, node, network_info, extra_md=extra_md, files=injected_files) # 触发部署请求 try: #调用ironic API,设置provision_state的状态ACTIVE self.ironicclient.call("node.set_provision_state", node_uuid, ironic_states.ACTIVE, configdrive=configdrive_value) except Exception as e: .... #等待node provision_state为ATCTIVE timer = loopingcall.FixedIntervalLoopingCall(self._wait_for_active, self.ironicclient, instance) try: timer.start(interval=CONF.ironic.api_retry_interval).wait() except Exception: ...
nova-compute的spawn的步骤包括:
- 获取节点
- 配置网络信息
- 配置驱动信息
- 触发部署,设置ironic的provision_state为ACTIVE
- 然后等待ironic的node provision_state为ACTIVE就结束了。
第四步
ironic-api接收到了provision_state的设置请求,然后返回202的异步请求,那我们下来看下ironic在做什么?
首先,设置ironic node的provision_stat为ACTIVE相当于发了一个POST请求:PUT /v1/nodes/(node_uuid)/states/provision。那根据openstack的wsgi的框架,注册了app为ironic.api.app.VersionSelectorApplication的类为ironic的消息处理接口,那PUT /v1/nodes/(node_uuid)/states/provision的消息处理就在ironic.api.controllers.v1.node.NodeStatesController的provision方法。
@expose.expose(None, types.uuid_or_name, wtypes.text,
wtypes.text, status_code=http_client.ACCEPTED)
def provision(self, node_ident, target, configdrive=None): .... if target == ir_states.ACTIVE: #RPC调用do_node_deploy方法 pecan.request.rpcapi.do_node_deploy(pecan.request.context, rpc_node.uuid, False, configdrive, topic) ...
然后RPC调用的ironic.condutor.manager.ConductorManager.do_node_deploy方法,在方法中会先检查电源和部署信息,其中部署信息检查指定的节点的属性是否包含驱动的要求,包括检查boot、镜像大小是否大于内存大小、解析根设备。检查完之后调用ironic.condutor.manager.do_node_deploy方法
def do_node_deploy(task, conductor_id, configdrive=None):
"""Prepare the environment and deploy a node.""" node = task.node ... try: try: if configdrive: _store_configdrive(node, configdrive) except exception.SwiftOperationError as e: with excutils.save_and_reraise_exception(): handle_failure( e, task, _LE('Error while uploading the configdrive for ' '%(node)s to Swift'), _('Failed to upload the configdrive to Swift. ' 'Error: %s')) try: #调用驱动的部署模块的prepare方法,不同驱动的动作不一样 #1. pxe_* 驱动使用的是iscsi_deploy.ISCSIDeploy.prepare, #然后调用pxe.PXEBoot.prepare_ramdisk()准备部署进行和环境,包括cache images、 update DHCP、 #switch pxe_config、set_boot_device等操作 #cache images 是从glance上取镜像缓存到condutor本地, #update DHCP指定bootfile文件地址为condutor #switch pxe_config将deploy mode设置成service mode #set_boot_device设置节点pxe启动 #2. agent_* 生成镜像swift_tmp_url加入节点的instance_info中 #然后调用pxe.PXEBoot.prepare_ramdisk()准备部署镜像和环境 task.driver.deploy.prepare(task) except Exception as e: ... try: #调用驱动的deploy方法,不同驱动动作不一样 #1. pxe_* 驱动调用iscsi_deploy.ISCSIDeploy.deploy() #进行拉取用户镜像,然后重启物理机 #2. agent_*驱动,直接重启 new_state = task.driver.deploy.deploy(task) except Exception as e: ... # NOTE(deva): Some drivers may return states.DEPLOYWAIT # eg. if they are waiting for a callback if new_state == states.DEPLOYDONE: task.process_event('done') elif new_state == states.DEPLOYWAIT: task.process_event('wait') finally: node.save()
至此,ironic-conductor的动作完成,等待物理机进行上电。
值得说明的是,task是task_manager.TaskManager的一个对象,这个对象在初始化的时候将self.driver初始化了 self.driver = driver_factory.get_driver(driver_name or self.node.driver)
driver_name是传入的参数,默认为空;这个self.node.driver指物理机使用的驱动,不同物理机使用的驱动可能不同,这是在注册物理机时指定的。
第五步
在上一步中已经设置好了启动方式和相关网络信和给机器上电了,那么下一步就是机器启动,进行部署了。下面以PXE和agent两种部署方式分别来说明。
情况一、使用PXE驱动部署
我们知道安装操作系统的通用流程是:首先,bios启动,选择操作系统的启动(安装)模式(此时,内存是空白的),然后根据相关的安装模式,寻找操作系统的引导程序(不同的模式,对应不同的引导程序当然也对应着不同的引导程序存在的位置),引导程序加载文件系统初始化程序(initrd)和内核初始镜像(vmlinuz),完成操作系统安装前的初始化;接着,操作系统开始安装相关的系统和应用程序。
PXE启动方式的过程为:
- 物理机上电后,BIOS把PXE client调入内存执行,客户端广播DHCP请求
- DHCP服务器(neutron)给客户机分配IP并给定bootstrap文件的放置位置
- 客户机向本网络中的TFTP服务器索取bootstrap文件
- 客户机取得bootstrap文件后之执行该文件
- 根据bootstrap的执行结果,通过TFTP服务器(conductor)加载内核和文件系统
- 在内存中启动安装
启动后运行init启动脚本,那么init启动脚本是什么样子的。
首先,我们需要知道当前创建deploy-ironic的镜像,使用的diskimage-build命令,参考diskimage-builder/elements/deploy-ironic这个元素,最重要的是init.d/80-deploy-ironic这个脚本,这个脚本主要其实就是做以下几个步骤:
- 找到磁盘,以该磁盘启动iSCSI设备
- Tftp获取到ironic准备的token文件
- 调用ironic的api接(POST v1/nodes/{node-id}/vendor_passthru/pass_deploy_info)
- 启动iSCSI设备, 开启socket端口 10000等待通知PXE结束
- 结束口停止iSCSI设备。
# 安装bootloader
function install_bootloader {
#此处省略很多
...
}
#向Ironic Condutor发送消息,开启socket端口10000等待通知PXE结束
function do_vendor_passthru_and_wait { local data=$1 local vendor_passthru_name=$2 eval curl -i -X POST \ "$TOKEN_HEADER" \ "-H 'Accept: application/json'" \ "-H 'Content-Type: application/json'" \ -d "$data" \ "$IRONIC_API_URL/v1/nodes/$DEPLOYMENT_ID/vendor_passthru/$vendor_passthru_name" echo "Waiting for notice of complete" nc -l -p 10000 } readonly IRONIC_API_URL=$(get_kernel_parameter ironic_api_url) readonly IRONIC_BOOT_OPTION=$(get_kernel_parameter boot_option) readonly IRONIC_BOOT_MODE=$(get_kernel_parameter boot_mode) readonly ROOT_DEVICE=$(get_kernel_parameter root_device) if [ -z "$ISCSI_TARGET_IQN" ]; then err_msg "iscsi_target_iqn is not defined" troubleshoot fi #获取当前linux的本地硬盘 target_disk= if [[ $ROOT_DEVICE ]]; then target_disk="$(get_root_device)" else t=0 while ! target_disk=$(find_disk "$DISK"); do if [ $t -eq 60 ]; then break fi t=$(($t + 1)) sleep 1 done fi if [ -z "$target_disk" ]; then err_msg "Could not find disk to use." troubleshoot fi #将找到的本地磁盘作为iSCSI磁盘启动,暴露给Ironic Condutor echo "start iSCSI target on $target_disk" start_iscsi_target "$ISCSI_TARGET_IQN" "$target_disk" ALL if [ $? -ne 0 ]; then err_msg "Failed to start iscsi target." troubleshoot fi #获取到相关的token文件,从tftp服务器上获取,token文件在ironic在prepare阶段就生成好的。 if [ "$BOOT_METHOD" = "$VMEDIA_BOOT_TAG" ]; then TOKEN_FILE="$VMEDIA_DIR/token" if [ -f "$TOKEN_FILE" ]; then TOKEN_HEADER="-H 'X-Auth-Token: $(cat $TOKEN_FILE)'" else TOKEN_HEADER="" fi else TOKEN_FILE=token-$DEPLOYMENT_ID # Allow multiple versions of the tftp client if tftp -r $TOKEN_FILE -g $BOOT_SERVER || tftp $BOOT_SERVER -c get $TOKEN_FILE; then TOKEN_HEADER="-H 'X-Auth-Token: $(cat $TOKEN_FILE)'" else TOKEN_HEADER="" fi fi #向Ironic请求部署镜像,POST node的/vendor_passthru/pass_deploy_info请求 echo "Requesting Ironic API to deploy image" deploy_data="'{\"address\":\"$BOOT_IP_ADDRESS\",\"key\":\"$DEPLOYMENT_KEY\",\"iqn\":\"$ISCSI_TARGET_IQN\",\"error\":\"$FIRST_ERR_MSG\"}'" do_vendor_passthru_and_wait "$deploy_data" "pass_deploy_info" #部署镜像下载结束,停止iSCSI设备 echo "Stopping iSCSI target on $target_disk" stop_iscsi_target #如果是本地启动,安装bootloarder # If localboot is set, install a bootloader if [ "$IRONIC_BOOT_OPTION" = "local" ]; then echo "Installing bootloader" error_msg=$(install_bootloader) if [ $? -eq 0 ]; then status=SUCCEEDED else status=FAILED fi echo "Requesting Ironic API to complete the deploy" bootloader_install_data="'{\"address\":\"$BOOT_IP_ADDRESS\",\"status\":\"$status\",\"key\":\"$DEPLOYMENT_KEY\",\"error\":\"$error_msg\"}'" do_vendor_passthru_and_wait "$bootloader_install_data" "pass_bootloader_install_info" fi
下面我们来看一下node的/vendor_passthru/pass_deploy_info都干了什么?Ironic-api在接受到请求后,是在ironic.api.controllers.v1.node.NodeVendorPassthruController._default()方法处理的,这个方法将调用的方法转发到ironic.condutor.manager.CondutorManager.vendor_passthro()去处理,进而调用相应task.driver.vendor.pass_deploy_info()去处理,这里不同驱动不一样,可以根据源码查看到,比如使用pxe_ipmptoos驱动, 则是转发给ironic.drivers.modules.iscsi_deploy.VendorPassthru.pass_deploy_info()处理,其代码是
@base.passthru(['POST'])
@task_manager.require_exclusive_lock
def pass_deploy_info(self, task, **kwargs): """Continues the deployment of baremetal node over iSCSI. This method continues the deployment of the baremetal node over iSCSI from where the deployment ramdisk has left off. :param task: a TaskManager instance containing the node to act on. :param kwargs: kwargs for performing iscsi deployment. :raises: InvalidState """ node = task.node LOG.warning(_LW("The node %s is using the bash deploy ramdisk for " "its deployment. This deploy ramdisk has been " "deprecated. Please use the ironic-python-agent " "(IPA) ramdisk instead."), node.uuid) task.process_event('resume') #设置任务状态 LOG.debug('Continuing the deployment on node %s', node.uuid) is_whole_disk_image = node.driver_internal_info['is_whole_disk_image'] #继续部署的函数,连接到iSCSI设备,将用户镜像写到iSCSI设备上,退出删除iSCSI设备, #然后在Condutor上删除镜像文件 uuid_dict_returned = continue_deploy(task, **kwargs) root_uuid_or_disk_id = uuid_dict_returned.get( 'root uuid', uuid_dict_returned.get('disk identifier')) # save the node's root disk UUID so that another conductor could # rebuild the PXE config file. Due to a shortcoming in Nova objects, # we have to assign to node.driver_internal_info so the node knows it # has changed. driver_internal_info = node.driver_internal_info driver_internal_info['root_uuid_or_disk_id'] = root_uuid_or_disk_id node.driver_internal_info = driver_internal_info node.save() try: #再一次设置PXE引导,为准备进入用户系统做准备 task.driver.boot.prepare_instance(task) if deploy_utils.get_boot_option(node) == "local": if not is_whole_disk_image: LOG.debug('Installing the bootloader on node %s', node.uuid) deploy_utils.notify_ramdisk_to_proceed(kwargs['address']) task.process_event('wait') return except Exception as e: LOG.error(_LE('Deploy failed for instance %(instance)s. ' 'Error: %(error)s'), {'instance': node.instance_uuid, 'error': e}) msg = _('Failed to continue iSCSI deployment.') deploy_utils.set_failed_state(task, msg) else: #结束部署,通知ramdisk重启,将物理机设置为ative finish_deploy(task, kwargs.get('address'))
在continue_deploy函数中,先解析iscsi部署的信息,然后在进行分区、格式化、写入镜像到磁盘。 然后调用prepare_instance在设置一遍PXE环境,为进入系统做准备,我们知道在instance_info上设置了ramdisk、kernel、image_source 3个镜像,其实就是内核、根文件系统、磁盘镜像。这里就是设置了ramdisk和kernel,磁盘镜像上面已经写到磁盘中去了,调用switch_pxe_config方法将当前的操作系统的启动项设置为ramdisk和kernel作为引导程序。 最后向节点的10000发送一个‘done’通知节点关闭iSCSI设备,最后节点重启安装用户操作系统,至此部署结束。
在部署过程中,节点和驱动的信息都会被存入ironic数据库,以便后续管理。
情况二、使用agent驱动部署
在部署阶段的prepare阶段与PXE一样,但是由于创建的ramdisk不一样所以部署方式则不一样,在PXE中,开机执行的是一段init脚本,而在Agent开机执行的是IPA。
机器上电后,ramdisk在内存中执行,然后启动IPA,入口为cmd.agent.run(),然后调用ironic-python-agent.agent.run(),其代码如下
def run(self):
"""Run the Ironic Python Agent.""" # Get the UUID so we can heartbeat to Ironic. Raises LookupNodeError # if there is an issue (uncaught, restart agent) self.started_at = _time() #加载hardware manager # Cached hw managers at runtime, not load time. See bug 1490008. hardware.load_managers() if not self.standalone: # Inspection should be started before call to lookup, otherwise # lookup will fail due to unknown MAC. uuid = inspector.inspect() #利用Ironic API给Condutor发送lookup()请求,用户获取UUID,相当于自发现 content = self.api_client.lookup_node( hardware_info=hardware.dispatch_to_managers( 'list_hardware_info'), timeout=self.lookup_timeout, starting_interval=self.lookup_interval, node_uuid=uuid) self.node = content['node'] self.heartbeat_timeout = content['heartbeat_timeout'] wsgi = simple_server.make_server( self.listen_address[0], self.listen_address[1], self.api, server_class=simple_server.WSGIServer) #发送心跳包 if not self.standalone: # Don't start heartbeating until the server is listening self.heartbeater.start() try: wsgi.serve_forever() except BaseException: self.log.exception('shutting down') #部署完成后停止心跳包 if not self.standalone: self.heartbeater.stop()
其中self.api_client.lookup_node调用到ironic-python-api._do_lookup(),然后发送一个GET /{api_version}/drivers/{driver}/vendor_passthru/lookup请求。 Condutor API在接受到lookup请求后调用指定驱动的lookup函数处理,返回节点UUID。
IPA收到UUID后调用Ironic-API发送Heartbeat请求(/{api_version}/nodes/{uuid}/vendor_passthru/heartbeat),Ironic-API把消息路由给节点的驱动heartbeat函数处理。Ironic-Condutor周期执行该函数,每隔一段时间执行该函数检查IPA部署是否完成,如果完成则进入之后的动作.目前agent*驱动使用的是ironic.drivers.modouls.agent.AgentVendorInterface类实现的接口,代码如下。
@base.passthru(['POST'])
def heartbeat(self, task, **kwargs): """Method for agent to periodically check in. The agent should be sending its agent_url (so Ironic can talk back) as a kwarg. kwargs should have the following format:: { 'agent_url': 'http://AGENT_HOST:AGENT_PORT' } AGENT_PORT defaults to 9999. """ node = task.node driver_internal_info = node.driver_internal_info LOG.debug( 'Heartbeat from %(node)s, last heartbeat at %(heartbeat)s.', {'node': node.uuid, 'heartbeat': driver_internal_info.get('agent_last_heartbeat')}) driver_internal_info['agent_last_heartbeat'] = int(_time()) try: driver_internal_info['agent_url'] = kwargs['agent_url'] except KeyError: raise exception.MissingParameterValue(_('For heartbeat operation, ' '"agent_url" must be ' 'specified.')) node.driver_internal_info = driver_internal_info node.save() # Async call backs don't set error state on their own # TODO(jimrollenhagen) improve error messages here msg = _('Failed checking if deploy is done.') try: if node.maintenance: # this shouldn't happen often, but skip the rest if it does. LOG.debug('Heartbeat from node %(node)s in maintenance mode; ' 'not taking any action.', {'node': node.uuid}) return elif (node.provision_state == states.DEPLOYWAIT and not self.deploy_has_started(task)): msg = _('Node failed to get image for deploy.') self.continue_deploy(task, **kwargs) #调用continue_deploy函数,下载镜像 elif (node.provision_state == states.DEPLOYWAIT and self.deploy_is_done(task)): #查看IPA执行下载镜像是否结束 msg = _('Node failed to move to active state.') self.reboot_to_instance(task, **kwargs) #如果镜像已经下载完成,即部署完成,设置从disk启动,重启进入用户系统, elif (node.provision_state == states.DEPLOYWAIT and self.deploy_has_started(task)): node.touch_provisioning() #更新数据库,将节点的设置为alive # TODO(lucasagomes): CLEANING here for backwards compat # with previous code, otherwise nodes in CLEANING when this # is deployed would fail. Should be removed once the Mitaka # release starts. elif node.provision_state in (states.CLEANWAIT, states.CLEANING): node.touch_provisioning() if not node.clean_step: LOG.debug('Node %s just booted to start cleaning.', node.uuid) msg = _('Node failed to start the next cleaning step.') manager.set_node_cleaning_steps(task) self._notify_conductor_resume_clean(task) else: msg = _('Node failed to check cleaning progress.') self.continue_cleaning(task, **kwargs) except Exception as e: err_info = {'node': node.uuid, 'msg': msg, 'e': e} last_error = _('Asynchronous exception for node %(node)s: ' '%(msg)s exception: %(e)s') % err_info LOG.exception(last_error) if node.provision_state in (states.CLEANING, states.CLEANWAIT): manager.cleaning_error_handler(task, last_error) elif node.provision_state in (states.DEPLOYING, states.DEPLOYWAIT): deploy_utils.set_failed_state(task, last_error)
根据上面bearthead函数,首先根据当前节点的状态node.provision_state==DEPLOYWAIT,调用continue_deploy()函数进行部署.
@task_manager.require_exclusive_lock
def continue_deploy(self, task, **kwargs): task.process_event('resume') node = task.node image_source = node.instance_info.get('image_source') LOG.debug('Continuing deploy for node %(node)s with image %(img)s', {'node': node.uuid, 'img': image_source}) image_info = { 'id': image_source.split('/')[-1], 'urls': [node.instance_info['image_url']], 'checksum': node.instance_info['image_checksum'], # NOTE(comstud): Older versions of ironic do not set # 'disk_format' nor 'container_format', so we use .get() # to maintain backwards compatibility in case code was # upgraded in the middle of a build request. 'disk_format': node.instance_info.get('image_disk_format'), 'container_format': node.instance_info.get( 'image_container_format') } #通知IPA下载swift上的镜像,并写入本地磁盘 # Tell the client to download and write the image with the given args self._client.prepare_image(node, image_info) task.process_event('wait')
Condutor然后依次调用:
- deploy_is_done()检查IPA执行下载镜像是否结束,
- 如果镜像已经下载完成,即部署完成,设置从disk启动,重启进入用户系统reboot_to_instance()
- 然后调用node.touch_provisioning() 更新数据库,将节点的设置为alive
至此,使用agent方式进行部署操作系统的过程到处结束。下面我们用两张图来回顾一下部署过程:
- 使用pxe_* 为前缀的驱动的部署过程
- 使用agent_* 为前缀的驱动的部署过程
下图是Liberty版的状态装换图
所有评论(0)