Neutron社区每周记(4.11~4.17)|OVS Agent 什么时候可以放心重启?

 

过去一周,Neutron社区都发生了什么事儿?...



编者的话:Neutron作为OpenStack网络模块,是核心组件之一。作为OpenStack发展的重点,社区每周都有一些新变化。UnitedStack有云网络组的同事将梳理这些变化,每周分享给大家。第一期内容受到广泛关注,这是第二期,我们跨出Neutron的界限,把相关社区的发展前景也一起盘点,希望朋友们一起来探讨社区发展的方向!

最概括

--社区Meeting上都说了啥?

  1. 下一版本Newton蓝图,具体请查看:https://launchpad.net/neutron/+milestone/newton-1,在可以从这里看Newton版本已经准备做的bp;
  2. API job is non voting,原因在与从tempest引入了一些灾难性的变更,Muller表示这个问题将在本周内修复;
  3. Fullstack/functional jobs测试也有不稳定的问题,有很高的失败率,现在只是想通过加更多的日志来调查失败的原因;
  4. 更多的gate测试可能会被引入,其中本周增加了一个关于interface使用场景(of_interface/ovsdb_interface)的测试,现在dvr相关的测试现在进入voting状态
最细节

--哪些Patch被Merge?

除了在社区会议上讨论的话题,上周还有很多Patch被Merge,其中maste分支merge的代码有接近一半是测试相关的。

  1. 有个patch修改了Neutron中devstack的相关脚本,使得在部署devstack的时候能够从git仓库中构建最新的OpenvSwitch,同时稍微做一些配置文件的修改,也能使用基于OpenvSwitch的Firewall Driver。这是否意味着 ovs based security group 已经可以进入大众面前使用?ovs based security group 的效果好不好?随着这个 patch,相信很快会有热心用户和开发者给出评测。
  2. DVR会给每个运行ovs-agent的节点分配一个DVR MAC,之前的做法是分配之后不进行回收,现在如果该host上的所有agent都被删除了,分配的DVR MAC也会被回收,用来防止ovs-agent生成了跟这个节点相关的无意义的flow,这个patch目前正在cherry pick到之前的release,其中Mitaka版本的正在被review: https://review.openstack.org/#/c/306703/
  3. quota的问题其实很鸡肋,在neutron-server多进程并发的时候很难保证资源的创建没有超过限制,结果 Orlando 花了半年多的时间去解决这个问题(http://specs.openstack.org/openstack/neutron-specs/specs/kilo/better-quotas.html)。之前的quota只是在functional tests中有少量测试,在本周merge的一个patch中给三大核心资源和l3、security group这些扩展资源的unit tests中加了quota相关的部分测试
  4. 从Kilo引入tempest之后,消除了tempest测试与neutron API测试用例之间个隔阂,同时现在完全引用tempest作为测试框架,相关代码在 neutron/tests/tempest/ 目录中,彻底抛弃了Neutron的API测试,这个patch也与例会中讨论的api job is non voting很相关。
  5. 其中一个特别重要的patch是关于router的管理的,router新增了一个状态ALLOCATING。这是由于router在l3 agent上创建的时候可能会有很多资源与之相关联,例如HA Router往L3 Agent上的调度会包含HA Network和HA Port的创建和更新过程,ALLOCATING这个中间状态使得这些资源的创建和更新封装成一整个大的事务;并且,当调度没完成之前,router的状态一直是ALLOCATING,在这期间不会通知L3 Agent端做相应的资源管理操作。
  6. 采用了在nova中已经使用过的方法,限制一个Neutron-Server进程内WSGI绿色线程的数量。之前的做法是WSGI绿色线程池的大小hardcode写的1000,这可能导致请求在一个进程内由于绿色线程数量过多导致需要等待可用的数据库连接,然而别的进程内有可用连接。现在新增加wsgi_default_pool_size并将其默认值由1000降低到100。
  7. 在代码重构方面,也有两个patch,分别是关于l3和IPAM的:精简l3_ha的部分检查逻辑,将其已到core plugin;精简IPAM中IP地址的分配方法中的一些判断逻辑。还有一个patch是用oslo_utils中相关的工具来替代之前在neutron中自己实现的关于shell cmd执行结果和API请求处理时候的字节和字符编码问题。
  8. 将ovs_use_veth和veth_mtu配置项标记为被弃用deprecated_for_removal,之前有这个配置项是由于OVS使用patch ports会出发老版本内核的bug,鉴于OpenStack Ocata版本部署时内核版本已经足够新了,所以这些配置项将在Ocata版本发布的时候彻底废弃。不过昨天 gark 提出了异议并上传了一个 revert 的 patch,他解释的原因是 DHCP 所用的 port 虽然叫 tap,但它其实是个 ovs internal device,从 ovs 这里建立出来,然后被我们移到了 dhcp namespace 中去,此时在 root namespace (也就是外边)是看不到这个设备的,但 ovs 却能管理它和转发流量,这一种比较 hack 的行为,所以他建议保留 ovs_use_veth,见 https://review.openstack.org/306807。
  9. 之前如果有多个物理网络,他们的MTU只能设置为一个相同的值,这种配置对于某些特殊的情况可能不太适用,现在可以分别为不通的物理网络设置不同的MTU,例如['physnet1:1500', 'physnet2:1500', 'physnet3:9000']
  10. 将 Openflow Agent 从 Neutron的发布周期中剔除
  11. 关于稳定版(cherry pick),有几个值得注意的是:我们之前认为 L3 HA 应该已经比较稳定了,但是还是被来自 HP 的开发者发现了问题,开启 L3 HA 会启动 keepalived 来做 VIP 切换,开启 keepalived 时呢需要留下来进城的 pid,如果节点意外关机或者发生故障等,那么这个文件不会清除,下次再开启  keepalived 时如果这个文件保存的 pid 恰好被用了(无论是不是 keepalived 进程),那么 keepalived 将无法启动。这个 Patch 在本周被 cherry-pick 回 m 版和 l 版分支:https://review.openstack.org/#/c/302818/ 。关心 ovs agent 重启的同学可能会注意到之前的代码可能会在重启时重建 br-int 到 br-tun 之间的 Patch 口,这个问题在本周也已得到修复:https://review.openstack.org/#/c/299243/。但真的修复全了吗?有开发者提交了另一个 Patch (https://review.openstack.org/#/c/305724/)提出 table 0 里的一条 resubmit 并没有很快的正确添加,这个 Patch 还在评审中…… 此外还有一个 patch 修改了 dvr 下 floatingip 的删除创建中条件竞争的问题:https://review.openstack.org/#/c/273235/,在使用 DVR 的厂商可能需要考虑修复。
  12. Andreas 提出了关于迁移虚拟机如果失败(例如 Port 有问题)那么虚拟机会置为 Error 状态,然而我们往往希望它能再迁回来(或者说放弃迁移),目前的机制无法解决,需要 Nova 和 Neutron 共同解决这个问题。
顺便说一句,Carl 正在收集运维中的痛点,在 Austin Summit 会有会议讨论,想吐槽的可以开始吐槽模式了。

其他社区

--OVS

社区正在开发支持 DPDK 16.04,相关的 Patch 已经发了出来指日可待;还有开发者在尝试通过 Rx checksum offload 的 feature 提升 OVS-DPDK 下 tunneling 的性能。

还有这么一个痛点,就是 DPDK 只能在启动 ovs 时配置,是否能让 netdev-dpdk 热插拔到 ovs 上也在最近开始尝试。

一个和 Neutron 关系很大的是 Neutron 中的 sfc、qos、taas 等等都需要 flow classifier,但是目前没有一个公用的机制,这也是一个很值得关注的事情。

最令人开心的其实应该是用户态的 conntrack 已经开始提交代码,或许我们在下一个版本真的能看到用户态的 conntrack ?!

其他社区

--OVN

QoS 的 DSCP 的支持正在开发,解决分布式 DHCP 的 metadata 无法用也在讨论,但是目前的方案很差,恐怕难以通过(在 ovs 里去加 http 头,可以想象吗?)
云计算-OpenStack-开源
关注“UnitedStack有云”
了解开源云资讯
精品技术库:https://www.ustack.com/about/blog/
企业联系人夏艳:xiayan@unitedstack.com
有云,世界更精彩


    关注 UnitedStack有云


微信扫一扫关注公众号

0 个评论

要回复文章请先登录注册