2016年的第一场Dragonflow Meetup在美丽的杭州开始了，会议由华为Dragonflow开源项目组成员发起，并邀请了中国区的Dragonflow开源贡献者一起参与了讨论，并由华为欧洲研究所专家Eran Gampel, Gal Sagie等为与会者带了Dragonflow最新的进展，以及当前任务的优先级和发展路线图。我作为Dragonflow外围技术男，有幸参与了为期一天半的会议，在此想为大家分享一下，在OpenStack的开源组件中，Dragonflow需要我们更多的关注，而作为SDN的实践者，也需要我们的贡献。

说到开源，我们首先会联想到的是免费。作为应用开源的企业，并非想到的是既得的实惠，如加速研发进度和缩减研发成本，而是另一种思路：标准。华为开源项目负责人李永乐说到：“OpenStack已经成为开源领域的IaaS的标准，企业的产品在符合业界标准交付时，会得到更多客户的认可，产品会有更强的竞争力，这也是华为积极参与Dragonflow的重要原因。”Dragonflow作为OpenStack网络服务的SDN解决方案，以实现大规模的网络基础设施服务为目标，推动该方案成为领域标准，并鼓励企业在该领域的解决方案引入其中，并作为标准进行实践，以得到更多的设备以及服务的支持。从这个意义上来说，从事云计算相关的企业，以SDN技术为基础，参与并推动Dragonflow的发展，对整个生态系统的发展是有益的，那么，通过开源项目构建产品的企业，积极参与和持续投入人力到开源项目中也是很有必要的。

从小的方面来说，不管是学习编程，还是实践SDN，您总可以在Dragonflow这个项目中挖掘出知识宝藏，Dragonflow为我们提供一个很好的实践开源软件的契机，让我们有机会，并有理由相信，通过实践我们必有收获。或许我可以从这一天半的会议中的小故事告诉您，参与到Dragonflow的开源社区中，您会有所收获。

1)开放。这次Meetup Meeting的成员来自很多实践在一线产品线上的工程师，他们在实践中提出了很多对Dragonflow相关的改进意见。比如小组成员在讨论到Dragonflow在集成网桥和外部网桥实现方案讨论时有意见分歧，Eran Gampel很友善的说：“你可以将这方面的设计起草方案，我们会在项目讨论组中公开讨论并审核。”Dragonflow不会做任何锁定设备和软件关联的解决方案，拥抱更多优秀设计于其中。

2)质量。可以说，Dragonflow贡献者们都非常认真的实践这个项目。来自海云捷迅的架构师马力再实践过程中发现了数据不一致导致的Bug，加入到了这次会议的讨论中，在这个过程中，充分体现了他在开源实践中技术实力，他提出的问题也引起了欧洲研究所专家们的高度关注，在经过1个多小时的讨论中，列举出4中解决方案，要知道每种解决方案的背后，涉及到的知识背景是深厚的，也充分的体现出他们对项目质量的要求非常之高，处理问题非常严谨和认真!

3)前瞻。Dragonflow项目的诞生，是站在巨人的肩上，出自一线实践者之手。在会议交流过程中，当问及为什么每个计算节点都会有一个Dragonflow Controller时，Eran Gampel的回答非常令人信服，他说：“我们曾经历过集中式控制器成为性能瓶颈的痛苦，而且集中式控制器会带来很多问题。当前采用分布式的控制方式，是未来发展的一个方向。Dragonflow Controller是非常轻量级的实现，它替代了之前Neutron Server的集中式DHCP以及集中的东西向流量处理方式，获得了更多的新功能和性能提升。其中实现的DHCP功能，只有400多行代码。”当然你可以说我们当前的产品不会达到上万的节点的部署，但是它的存在，不影响你的产品，反而会获得更多好处。

虽然当前国内开源大环境不是很景气，但是我们依然有很多令人振奋人心的故事。在这次Dragonflow Meetup中，汇聚了来自华为、有云、海云捷迅等公司的技术人员，他们一直致力于OpenStack的社区，成为Dragonflow的有力的实践者，使得公司的产品随着推动开源的过程中，快速迭代。记得在2015年12月10在南京召开的SDN峰会的圆桌论坛上，讨论过开源项目的实践，很多企业纷纷表态今后会投入更多的人力参与到优秀的开源项目中，他们一致认为，中国在开源力量上贡献实在有限，而这只会造成生态环境的恶性循环，闭门造车最终忘却选择开源的初心。京东云平台系统技术部架构师鲍永成在峰会上展示了他们利用OpenStack在私有云上取得的巨大进步，声称他们会继续对OpenStack开源社区持续贡献，包括在OpenStack与SDN整合方面的技术会有更多分享。