Archive for openstack

Openstack Neutron组件服务(neutron-dhcp-agent服务)

neutron-dhcp-agent服务启动命令 /usr/bin/neutron-dhcp-agent --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/dhcp_agent.ini 调用了neutron_service.Service.create()来创建的server。Service(n_rpc.Service)继承自neutron_lib.rpc,这次得去看看了,感觉应该也没啥看的。 Service(service.Service)继承自oslo_service.service.Service,里边只是个定义类接口,里边还有个线程池self.tg。 Service传入的manager为neutron.agent.dhcp.agent.DhcpAgentWithStateReport, 然后实例化,最后初始化父类。 DhcpAgentWithStateReport继承自DhcpAgent,再继承自manager.Manager, 然后继承自periodic_task.PeriodicTasks,看起来是个定时任务。先不细看了,按初始化流程走。 在DhcpAgent里dhcp_driver_cls存的dhcp_driver的类,文档安装使用的neutron.agent.linux.dhcp.Dnsmasq,这个先记录,后边看。DhcpPluginApi这个是定义了dhcp rpc的client端,从注释看server端在neutron.api.rpc.handlers.dhcp_rpc.DhcpRpcCallback,具体还不知道为啥这么搞,先记录。看接口内容感觉就是网络的几个常规接口。DhcpAgentWithStateReport里的初始化,也是初始化了一个心跳进行状态上报。 launch方法传入初始化完的server, 启动一个进程,restart方法mutate_config_files on SIGHUP,这个先记录。workers为1走的是ServiceLauncher,继承自Launcher,然后初始化Services,这个也有个线程池。最后初始化SignalHandler。.wait()里边看注释是等待重启服务的信号. 看了一下DhcpRpcCallback,这个看不太懂了,其中的plugin的初始化不太清楚。状态不行,不看这个了。 Dnsmasq继承自DhcpLocalProcess, 再继承自DhcpBase,初始化了一个DeviceManager是与之前的rpc调用相关的没细看。 是通过call_driver来实例化的,但是看起来都是用到的时候才初始化的,看初始化方法和调用,基本都是传入network和action然后,初始化完成后,执行action的方法,所以应该是针对不同网络进行实例化并操作。 主要逻辑都是在Dnsmasq里定义的,existing_dhcp_networks看注释是返回dhcp网络,直接从配置文件目录读取,这个也说明创建网络会在这个目录创建配置文件。_build_cmdline_callback看样子是启动dnsmasq的命令生成的地方。spawn_process启动dnsmasq的进程,调用_get_process_manager,这个是在DhcpLocalProcess, 然后还加入监控。启动是先使用external_process.ProcessManager初始化ProcessManager类,在调用enable()通过传入的cmd_callback,也就是_build_cmdline_callback那个生成cmd,启动服务进程. 随便看了一下,流程连不起来了。这里代码太绕了,不知道怎么个调用的。感觉流程最好搭个环境,打打日志比较好。 这个看的有点失败,获得了很少的东西。
Read more...

Openstack Neutron组件服务(neutron-metadata-agent服务)

供应商网络依赖的几个服务: neutron-server.service neutron-linuxbridge-agent.service neutron-dhcp-agent.service neutron-metadata-agent.service 自服务网络除了上边的几个服务外还依赖 neutron-l3-agent.service。 从这里也能看出,自服务网络支持三层模拟,这也是主要区别。自服务可以实现的功能就比较多,比如vxlan,FWaaS,LBaaS等。 先看看neutron-metadata-agent服务,这个服务主要功能是实例启动的时候为cloud-init获取metadata的时候转发用的。因为实例所在网络跟nova-api网络肯定不通的,所以需要一个中间转发,起这个作用的就是neutron-metadata-agent服务。看网上从实例到neutron-metadata-agent服务,中间还经过了haproxy,haproxy是l3-agent或者dhcp-agent启动的,这个也许也是分不同网络类型正好不同(但是我看官方安装文档,两种网络方式配置都是使用dhcp来启动的metadata服务, 默认是通过l3-agent启动)。然后由haproxy转发给neutron-metadata-aget,然后neutron-metadata-agent转发给nova-api-metadata服务。 服务启动命令为/usr/bin/neutron-metadata-agent --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/metadata_agent.ini 很多小模块过掉了,必须要看的时候再梳理吧。 主要是启动一个UnixDomainMetadataProxy。然后调用了agent_utils.UnixDomainWSGIServer启动,在文件neutron/agent/linux/utils.py 里,这个文件定义了好多不同类型的agnet。不得不说Openstack模块封装的太好了,接口封装的好,看起来就基本靠猜就可以了。看代码是启动了一个wsgi服务,handler为MetadataProxyHandler。然后调用_init_state_reporting,这个我看可以设置心跳,主要上报了监听的地址端口之类的信息,感觉也就监控或者排查问题有用。有个agent_rpc/context,也不知道往哪里上报的,先记住不看了。 MetadataProxyHandler里也有一个rpc(MetadataPluginAPI)/context,感觉这里不知道不行,靠猜也许行。 精简了就两行代码 instance_id, tenant_id = self._get_instance_and_tenant_id(req) return self._proxy_request(instance_id, tenant_id, req) 第一行从header里获取请求的信息,得到实例id,我看还做了rpc调用,具体获取啥先不看了。 第二行是转发请求,把实例id和租户id,通过header传递,用requests模块发送请求给nova。返回内容无误后,返回给wsgi,请求就结束了。 好多细节没看,不过不影响流程,整个流程就是一个转发,涉及配置和验证,还有rpc没看。整体没啥复杂流程,就先这样了。
Read more...

openstack使用pbr插件扩展setup.py,寻找服务入口

在setup.py里只需要写很少的代码,所有配置都放在setup.cfg里。如果参数通过setup()传入,以setup.cfg里的配置为准 #!/usr/bin/env python from setuptools import setup setup( setup_requires=['pbr'], pbr=True, ) setup.cfg里配置跟ini文件差不多。 [files]定义代码包里文件的安装目录,其中packages指定要安装的包;namespace_packages制定有命名空间的包;data_files指定要安装的文件的源地址和目的地址; [entry_points]指定模块入口点的运行脚本和模块。主要定义一些控制台脚本,pbr会自动生成这些脚本,做到脚本的跨平台。等号后边就相当于脚本执行调用的函数 随便看了两眼pbr源码: console_scripts就是两行,先import,后执行。 wsgi_scripts比较多,从代码来看,可以直接当脚本启动一个server或者,返回一个app提供给wsgi调用 知道了这个,基本就了解openstack一些模块入口函数怎么找了 看了看neutron service启动命令为 /usr/bin/neutron-server --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini neutron-server脚本在console_scripts里定义。 openstack rpm包打包项目https://github.com/openstack/rpm-packaging
Read more...

1