Austin OpenStack Summit后，Neutron社区又有哪些变化？本期围绕开发目标、方向、架构等展现Neutron最新动态，希望更多的Neutron开发者参与并讨论，群策群力！

Mailing List

［1］https://etherpad.openstack.org/p/newton-neutron-future-neutron-architecture
［2］https://etherpad.openstack.org/p/newton-neutron-future-neutron-api
［3］https://etherpad.openstack.org/p/newton-neutron-future-neutron-client
［4］https://etherpad.openstack.org/p/newton-neutron-community-stadium-evolution
［5］https://etherpad.openstack.org/p/newton-neutron-future-adv-services
［6］http://www.gossamer-threads.com/lists/openstack/operators/54512
［7］https://etherpad.openstack.org/p/newton-neutron-troubleshooting

有些规划正在call for volunteers, Neutron开发者们可以重点关注。

1、Neutron Architecture

关于Neutron控制平面的讨论。考虑提炼 Agent(l2/l3) 的公共代码为agent framework，讨论是否能够转化为一个单一的agent，根据不同的配置承担不同的角色 (l2/l3)；另一方面是往Oslo VersionedObjec迁移。

2、Neutron API

Keystone V3 的兼容，努力实现采用Pecan作为默认API框架；这些变更都需要保持向后的兼容性。

3、Neutron Client

重点在于向openstack-client 迁移的一些细节和Newton Scope 。目标想要解决neutron-client与openstack-client之间的gap，完成所有neutron-*aas cli的迁移，同时所有新增加的API必须支持openstack-client

4、Neutron 第三方集成

Neutron的stadium从2015年被提出来，解决当时众多第三方或者和Neutron关系不是特别大的项目的“名义”问题，经过一年多的发展，可以说成果斐然：

然而也带来一些问题，那就是PTL需要费很多精力关注这些项目，而且 Release Team和Core Team也需要花费时间和精力，而且非开源项目往往牵扯比较复杂，所以在这个Session中讨论重新定义清楚Neutron的交付、组成，和成为“OpenStack Networking”社区的意义。目前的讨论结果是形成一份Neutron-API Project名单，这个里边的项目将对Neutron本身会产生较大影响，例如neutron-lbaas、networking-ovn、networking-bgpvpn这些项目。目前还不是最终定论。

Plumgrid 的一位开发人员对这个讨论结果并不满意，认为这是对非开源SDN 项目集成的阻碍，大家在邮件列表里（包括 Armando、Kyle Mestery、Gal Sagie）发表了很多意见和讨论。

5、Neutron Diagnostics & troubleshooting

Neutron网络的排查是社区问答网站排名第一的问题，对于缺乏网络基础的人或者没有研究过Neutron的人，却是很难弄清，即使熟悉的人往往也需要花费很多时间。

Assaf在邮件中提到Neutron代码内是否能实现一个neutron-diagnostics-agent，帮助管理员检查网络问题？以后你只需要执行一句neutron floatingip-health <fip> 就可以检查floating的状态。
在Session上，大家提到了UnitedStack有云向社区贡献的Steth项目。

6、Neutron 高级服务

Neutron VPNaaS、FWaaS长期处于不活跃的状态，贡献者乏善可陈，根据前面stadium evoluution的讨论，如果Ocata-1之前没有改善，甚至这两个项目可能被移出networking stadium！

7、Neutron 用户与运维痛点

Carl 做了一些总结，主要在这些方面：
当 Active Agent 不够时，无法成功创建 HA Router；
当 L3 Agent 只有两个时，无法成功执行 l3-agent-router-remove（需要确认）；
升级时自动检查配置项，不过Carl说他们（HP？）在上次升级是完全自动的；
安全组中的IP协议数字；
还有一些已经有人在做的：Metadata 的 Nginx 后端、安全组的Scale问题（在大规模部署时很常见，主要是源选择本安全组这条默认规则）、IPv6 DVR、不需要SNAT可以直接路由的DVR网络

8、networking-sfc project IRC meeting

除了上述Neutron的内容，另一个引人注意的点networking-sfc的meeting topics。看起来是一番宏图大计，讨论了OVN， ODL，Tancker等的一系列driver和 ONOS的集成状态，参见: https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting

Merged Patches

［1］从iptables_manager移除address scope相关的代码，避免不必要的调用。上层服务(FWaaS, security group)需要address scope相关的规则时自己单独初始化
［2］试图解决IPAM过程中发生死锁异常之后的回滚:https://review.openstack.org/306519
［3］实现openvswitch driver 将 IPv6 地址作为隧道网络的地址，即ovs-agent 的local_ip: https://review.openstack.org/257335
［4］在RPC client端给RPC调用增加了一个装饰器，处理RPC调用失败重试时间的指数退避法则: https://review.openstack.org/280595
［5］一系列关于DVR中device和namespace的变更: https://review.openstack.org/309592 , https://review.openstack.org/309591
［6］解决多worker进程并发工作状态下，fork 子进程可能导致的不安全问题: https://review.openstack.org/276842
［7］引入oslo_db中paginate_query方法，应对不同的oslo_db版本所需要对排序的keys和方向进行对应的转换，并修改了一些异常信息中的语法问题: https://review.openstack.org/285863

OVN

在netorking-ovn模式下，OVNPlugin取代Ml2Plugin成为core_plugin，这种做法与很多Neutron ＋ ML2部署方案不兼容，并非是一个好的实现方案。

core_plugin = networking_ovn.plugin.OVNPlugin
#core_plugin = neutron.plugins.ml2.plugin.Ml2Plugin
在本周提出了将OVNPlugn转化为ML2 Driver的方法，而且已经开始频繁提交代码，这是一个好势头
具体描述见 https://bugs.launchpad.net/networking-ovn/+bug/1578198