把这一条trace完,让它更清晰吧,接着上一节,build_instances时,message的direction为down,选中child_cells中的一个:
next_hop.send_message(self)
执行CellState的send_message方法,即self.driver.send_message_to_cell(self, message),
前面提到的driver出来了,现在cells的方式还不是很复杂,这里的driver是rpc_driver.CellsRPCDriver(),即nova.cells.rpc_driver.py
其实看到这里,我们忽略了前面的一个动作,当nova-cells服务启动时:
self.manager.pre_start_hook()#CellsManager没有实现此方法,不管
self.manager.post_start_hook()#CellsManager实现了此方法
在post_start_hook中:
self.driver.start_servers(self.msg_runner)
ctxt = context.get_admin_context()
if self.state_manager.get_child_cells():
self.msg_runner.ask_children_for_capabilities(ctxt)
self.msg_runner.ask_children_for_capacities(ctxt)
else:
self._update_our_parents(ctxt)
这里的driver,目前没有别的选择,正是rpc_driver.CellsRPCDriver(),在start_servers中:
proxy_manager = InterCellRPCDispatcher(msg_runner) #记住这里,收到message时的处理类(manager)
for msg_type in msg_runner.get_message_types():
target = messaging.Target(topic='%s.%s' % (topic_base, msg_type),server=CONF.host)
topic_base:cells.intercell,msg_type为前面提过的targeted,broadcast,response三种,三个consumer都起来了
再回到self.driver.send_message_to_cell调用InterCellRPCAPI的该方法,这里和所有的rpc call没什么差别:
topic = '%s.%s' % (topic_base, message.message_type)
cctxt = self._get_client(cell_state, topic)
if message.fanout:
cctxt = cctxt.prepare(fanout=message.fanout)
return cctxt.cast(message.ctxt, 'process_message',
message=message.to_json())
根据message 是否是fanout,已经配置时指定的transport,在cell内发rpc call,收到时的处理方法是“process_message”,前面提到过cell内部收到
message的处理类是InterCellRPCDispatcher,调用其process_message:
message = self.msg_runner.message_from_json(message) #在MessageRunner中根据message 的type生成Message(targeted,broadcast, response)
message.process() #调用message的处理方法
到这里从nova-api(parent cell)进来的rest call(请求)到如何响应的流程就出来了,其他的细节包括子cell向父cell汇报状况,message响应过程等,
如果你需要真正的开发cells,再细看即可。
mark link
http://www.ibm.com/developerworks/cn/cloud/library/1409_zhaojian_openstacknovacell/index.html