Mailing List

在本周的邮件列表中讨论最多的话题是关于容器网络的，与之相对应的项目为 Kuryr。
Kuryr 是一个在 Docker 中管理容器网络的插件，借助 Neutron 为 Docker 容器提供网络服务。关于Kuryr 的更多介绍参考Wiki： http://docs.openstack.org/developer/kuryr/
其激烈讨论也说明现在容器在生产环境中的重要地位。其中一个关于Neutron 与 Kuryr 中 Port 状态同步的问题：当 Kuryr 请求 plug 一个 Port 的时候，在 Neutron 这边是一步的动作。Neutron 会通知相关的 Driver 去配置这个Port 对应的 VIF，返回 API 调用，最后由 agent 回调更新数据库中 Port 的真实状态。所以此时会出现的问题是 API Caller 得到的不一定是真实的 Port 状态（可能由于 Driver 配置 VIF 失败导致 Port 更新为 Error 等其他场景）。所以 API Caller 为了获取这个 Port 的真实状态，就需要采取特别的方法，例如：
1、轮询获取 Port的 状态 （poll）
2、监听消息队列中 port_update 的相关事件 （组件之间正常通信显然不可取）

同样的场景，Nova 也会遇到这个问题，需要确认虚拟网络正常配置完成之后才会去启动虚拟机。Nova 选择的是另一种截然不同的路径：在 Neutron 认为 VIF 确定之后，调用 Nova 的 API 去通知 Nova 这个 Port 的状态，即“neutron nova interactions”，需要配置 nova_url/nova_admin_username 等等参数。对应的实现方法：http://git.openstack.org/cgit/openstack/neutron/tree/neutron/notifiers/nova.py
这个实现的不优雅之处在于与 API Caller 的紧耦合：需要参考 Nova 再去写一遍关于 Kuryr 的重复代码。
邮件列表中由开发者提到了用 ping 的方法监控链路状态，因为对大部分 Driver 来讲，Port 状态为 Active 至少认为这个 VIF 二层是通信没有问题的，再由 ｀docker network connect –ip=W.X.Y.Z …｀设置。这个方法也受到其他因素比如安全规则或者 DHCP 等的限制。

作者倾向于实现通用的 notifiers 框架，由 Neutron 去通知对应的 API Caller，这样能够减少 poll 时候导致的 CPU 做高负载且无用功问题，然而这个框架需要对现有的实现一个大的修改；最终邮件列表中大部分人赞同用 poll 的方法。

Merged Patches

1、DHCP方面的改进
［1］Refactor NetworkDhcpAgentBinding，dhcp-agent 重构：https://review.openstack.org/328452
［2］DHCP: delete config option dnsmasq_dns_server ：https://review.openstack.org/329306

2、ovs及agent方面的改进
［1］ovs: set device MTU after it’s moved into a namespace，namespace 漂移时设置虚拟设备的MTU： https://review.openstack.org/331542
［2］Mark port as ready after enabling dhcp at agent， https://review.openstack.org/327062

3、数据库方面的改进
［1］Use session delete for IPs to trigger events，替换原来的 query.delete() https://review.openstack.org/328186
还有很多patch是关于测试用例的改进，可以订阅相关的邮件列表和 review 查看。

OVN

有个重要的 bp 提出来，通过 BGP EVPN 的 IP Prefix route 实现动态路由： https://review.openstack.org/#/c/322654/