尽管OpenStack的Juno版本已经到了beta3阶段离正式发布不远了,neutron这个网络组件也已经接近成熟,但仍有用户希望采用nova-network这种非集中式的网络解决方案(与cloud stack类似),大概是由于其天生就是分布式的概念,部署也简单许多。

最近客户在部署我们基于neutron ML2机制实现的OpenStack网络解决方案时,发现实例总是无法正确创建,从调用栈上看是网络客户端api调用allocate_for_instance函数出现rpc timeout,由于我们的方案基于neutron,nova组件与neutron之间应该采用neutronclient这个python库并通过RESTful接口进行通信,不该进行rpc通信。

晚上的代码阅读,发现用户应该是未正确配置nova配置文件中的network_api_class配置项,从nova/network/initpy中的如下代码:

_network_opts = [
    oslo.config.cfg.StrOpt('network_api_class',
                           default='nova.network.api.API',
                           help='The full class name of the '
                                'network API class to use'),
]

可以看出在未配置network_api_class时,采用的是nova.network.api.API这个类,而该类,则是基于nova-network服务来实现实例的网络功能的,而用户根本未起nova-network,自然rpc无人监听了,出现rpc timeout也是自然的问题了。

这里值得提醒一点的是,nova抽象了nova.service.Service这个用于提供rpc服务的机制,在nova/cmd/network.py中的如下代码中:

def main():
    config.parse_args(sys.argv)
    logging.setup("nova")
    utils.monkey_patch()
    objects.register_all()

    gmr.TextGuruMeditation.setup_autorun(version)

    if not CONF.conductor.use_local:
        block_db_access()
        objects_base.NovaObject.indirection_api = \
        conductor_rpcapi.ConductorAPI()

    server = service.Service.create(binary='nova-network',
    topic=CONF.network_topic,
    db_allowed=CONF.conductor.use_local)
    service.serve(server)
    service.wait()

nova-network这个程序通过Service创建了nova-network这个服务,该服务将监听来自于计算服务的rpc请求,为实例分配网络资源。


Comments

comments powered by Disqus