OpenDaylight Neutron北向接口项目深探

在云时代，对于学习SDN的程序员来说，OpenStack Neutron和OpenDaylight毫无疑问是两大技术金矿。但是对于程序员来说，要跨这两个社区意味着Python，JAVA两大技术群。所以借句套话来说就是“既是机遇，也是挑战”。OpenStack社区已经存在5年多了，OpenDaylight才不到三年的时间。相比OpenStack来说，OpenDaylight在管理上显得不是很清晰，文档的更新和即时性也比较差。借助于本人在Java领域的经验，在研究了各种相关技术和代码后，总结了一下OpenDaylight北向接口的技术内密。

Neutron北向接口概述
当然要了解这个项目，项目的wiki站点https://wiki.opendaylight.org/view/NeutronNorthbound:Main 无疑是最好的地方。项目的freenode IRC频道是＃opendaylight-neutron，虽然wiki主站点标的是＃opendaylight。从这个频道的参与人数来看（如下图），这个项目的参与度不是很高。而且几个核心经常不在线，但有可能是我们时区的原因。

好了，我们接着聊聊这个项目的主要目的：

• 1. 让ODL和Openstack Neutron对接
• 2. 隔离Neutron和Opendaylight各自的内部实现细节
• 3. 给Opendaylight各个网络项目提供neutron的虚拟网络接口
• 4. 吸引更多的开发者进入社区

前两个目的显而易见，我们说说第三和第四条。

如上图，现在Opendaylight和openstack neutron的集成有多个项目，比如VTN，DOVE和OVSDB。它们都通过neutron北向接口和OpenStack neutron通信。

对于吸引更多的开发者，那就是说，投身于社区的开发人员在理论上来说是固定的，如果能把OpenStack的开发人员吸引部分到Opendaylight里来，这对于社区的发展肯定是件好事。下面是两个社区频道参与人员的数量：

不难发现，两个社区的人员参与度不在一个量级。这也许是opendaylight涉及的领域比较专的原因，而且做java的开发者大都在做企业应用，对于用java做网络，大家还是有点不习惯。

Neutron北向接口项目的结构
我们安装了opendaylight后，进入karaf控制台，执行bundle:list | grep neutron可以看到这个项目的bundle，如下：

各个模块实现了各自的功能，它们之间的依赖关系大概如下：

1. northbound-api主要是提供restful接口，把从openstack 过来的调用转向transcriber项目中的服务。

2. neutron-spi项目提供restful接口的数据模型，也就是restful接口的http数据会直接转换成这里对应的数据对象。当然这个SPI还定义了一些服务接口，来和northbound-api对接。

3. transcriber项目实现了neutron-spi中定义的服务接口，它把restful接口传递进来的数据转换成ODL的MD数据库中的model。

4. model定义了这个项目在ODL中的neutron表述。Restful接口传进来的数据通过transcriber的处理，从Neutron-spi中的模型转换成MD中model定义的模型。当然对于Restful中需要访问数据的接口，transcriber把ODL中的model定义的数据转成neutron-spi定义的数据模型，再通过restful接口暴露给Openstack的模块。

northbound-api的restful接口
northbound-api是个WAR模块，也就是说它是一个web应用。它的web 根目录定义在maven 构建插件生成的MANIFEST.MF文件中：

也就是如上图所示的“/controller/nb/v2/neutron”。当然作为一个J2EE web应用模块，web.xml文件是必不可少的：

而且还可以看出我们的API是一个jersey容器下跑的一个应用。Karaf的配置目录下，我们可以看到jersey容器的配置文件：

从上图可知jersey的监听地址是8181和8080。这也是我们为什么会有http://localhost:8181/index.html看到DLUX界面的原因。

RESTFUL 接口调用示例
RESTFUL接口针对neutron的网络模型对各个对象都有增删改查的URL。这里我们针对网络这个资源对象来演示这个API的使用。

下面我们先创建一个虚拟网络:

然后再获取所有虚拟网络：

当然，我们也可以单独显示某个虚拟网络：

和删除网络：

northbound-spi 定义API接口后面的数据模型和操作接口

如上图所示，NeutronNorthboundRSApplication是web应用入口，其定义了系统所有的URL映射类，比如为网络对象的NeutronNetworksNorthbound，为子网对象定义的NeutronSubnetsNorthbound。这些northbound类定义了各个对象的增删改查URL映射。

下面我们只描述为网络对象定义URL接口的NeutronNetworksNorthbound类。它的定义如下：

可以看到它的映射前缀是：“/networks”，首先看看Network List操作的映射:

我们看看这个方法的各种annotation。首先是@Get，这表明是个HTTP Get方法。接着是状态码的定义，然后是方法内部对于各个URL查询参数的映射。然后调用SPI模块中的接口INetworkNetworkCRUD来获得系统中的网络对象NeutronNetwork，接着循环处理这些网络对象。

下面是这个方法的后半部分：

分两种情况，第一种是分页，第二种不分页。但是最后还是创建一个NeutronNetworkRequest对象对NeutronNetwork进行了封装：

这个类定义了它的JAXB映射，这样容器就能把模型数据进行序列化和反序列化。
Transcriber 在SPI模型和MD模型之间转换

Transcriber模块定义了一系列实现类来实现SPI模块中定义的各种CRUD接口。这些实现类主要工作就是在SPI模型和model模块中定义的yang模型之间进行映射。同时通过 ODL的MD服务对yang模型进行存储访问。

Transcriber模块是一个典型意义上的OSGI bundle，它定义了自己的activator，这个activator启动的时候，注册了实现SPI CRUD接口的所有服务类。如下图所示：

这样，在API中调用SPI的接口时，其实调用的是transcriber中实现的类。

前面谈到了transcriber的启动，其装配了SPI实现的接口，下面的图形便展示了其映射网络模型的fromMd和toMd方法：

yang模块定义了neutron网络的MD SAL模型
Opendaylight中大量运用了yang技术，它很好地配合了网络设备厂商的NETCONF技术。Yang模型既能定义数据，也能定义RPC方法和通知。要学好Opendaylight，了解Yang是个必备的前提。当然其它的技术还有JAVA，MAVEN，OSGI，J2EE等。

如上图，这个模块基本上就neutron网络模型中的每个对象都有相应的定义。

ODL给yang模型提供了restconf接口，只要项目定义好yang模型，被装载进ODL后，系统就可以为这些模型提供restconf接口。用户可以直接调用这些接口用以操纵模型数据。下面我们演示一下这个操作过程。

首先我们得确保系统安装了odl-restconf feature：

然后可以使用下面的cURL命令访问我们的虚拟网络模型。比如显示所有网络：

创建网络：

后 记
Neutron北向接口项目本身在不断地发展，它的架构和代码会继续演进，该篇文章的深度探索只是针对目前版本的技术分析。

当然，希望大家积极参与社区贡献，为项目的成熟贡献自己的力量。就像前面所说，在Opendaylight中做开发是个很有挑战性的工作，要求的知识面和技术实力都比较高，能在这里遨游本身就是对自己的肯定。

对于neutronnorthbound项目，既能ODL提供了restconf接口，我认为有这么一天，自己定义的restful接口将会消失，转而直接使用MD yang模型的restconf接口。
转载自：九州云

声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。