OpenDaylight的终端用户现在可以放心的是,OpenDaylight早起版本中的数以千计的功能支持不足的现象一去不复返了。OpenDaylight最新的版本Carbon展示了该平台的用户一直期待的成熟度和生产级质量,该版本能够显著改善安全性、稳定性和网络可编程性。
OpenDaylight Carbon版本的推动目标是提高ODL服务的稳定性和可靠性。也就是说几个项目可以使用Aries Blueprint进行定制配置子系统的服务激活,这一工作从Boron版本中开始,在Carbon版本中得到了改进。Blueprint在该版本中更容易记录和调试,从而产生更有效且令人满意的应用程序开发试验。由于Blueprint支持并行服务激活,启动控制器和提供服务之间的延迟较少,应用程序配置与代码布线分开,因此可升级性得到改善。这是非常重要的,因为大多数升级OpenDaylight的运营商希望能够在不同版本之间保持配置,且接收内部布线更改。
为每个项目添加Apache Karaf 4.X功能是希望在OpenDaylight下一个版本Nitrogen版本中使用新的容器,此外Carbon版本还增强了测试功能,以确保功能导入所有适当的运行时包,从而提高ODL功能的稳定性。这一基础有助于社区的开发者在Nitrogen版本开发周期中执行Karaf升级。
Yang 1.0数据建模语言的RFC 6020已经被新的Yang 1.1数据建模语言RFC 7950所取代,对于应用程序开发人员来说,这意味着他们现在可以在Yang模型中使用Yang 1.1结构。此外,使用RFC 7950的南向Netconf设备的互操作性在Carbon版本中成为可能。
NETCONF集群实现通过集群单例服务进行重新架构变得更加稳定,并大大提高了测试覆盖率。最终用户可以实现与Boron版本一致的NETCONG集群体验,但是在分布式控制器部署中可以更放心地使用NETCONF。
尽管目前还没有任何消费应用程序,但是Carbon版本中包含了MD-SAL Binding Specification version 2的前瞻性版本,新版本的绑定规范解决了初始版本中发现的几个问题。该版本是基于Twirl实现,具有与V1版本规范中xtend相似的功能,但是是以Scala而不是Java生成代码。生成的Scala代码被注入到Java运行环境中,并且可以被传统的Jaca客户端访问。
Carbon版本包含最新的标准化的RFC 8040,RESTCONF的实现。到目前为止,OpenDaylight用户可能最熟悉与RESTCONF Draft 02 API进行交互,Draft 02 API仍然在OpenDaylight中很好的兼容,因为很多软件仍然依赖该API实现。新的RFC 8040RESTCONF API通过单独的端点提供,OpenDaylight鼓励用户开始探索并使用标准版本的API,因为社区支持DRAFT 02版本的时间具有很大的不确定性。
此外,通过在AAA项目中添加基于模型的授权模式,可以提高RESTCONF的安全性。运营商现在可以在运行时将URL端点集合动态限制为特定类别的用户,这种加强的授权机制适用于两种RESTCONF版本。AAA贡献者还增加了对基于模型的证书管理的支持,虽然证书管理功能目前旨在Carbon版本中与OVSDB相集成,但计划在未来提供与其他南向协议的集成。
在NETCONF项目中添加了基于IETF Call Home的Draft 08初始实现,该实现目前不是集群感知,而是提供呼叫归属功能的基本功能。总体而言,这改善了OpenDaylight的集成点,并增强了运营人员将ODL自动化的能力。
Carbon新增的一个项目是Daexim,该项目支持以JSON格式导入和导出MD-SAL数据存储区的数据。Daexim在指定版本之间不能支持Yang数据模型的更改,开发人员可以编写外部裸机来操纵导入导出的数据,从而为ODL版本之间的升级提供便利。
此外,Carbon还包括 jsonrpc的首个具体化应用,该项目旨在加强与控制者的外部沟通和联合。jsonrpc为ZMQ公开了一个经过良好测试的版本。相比较于RESTCONF、NETCONF或其他一些北向接口,应用程序开发人员可以挂接总线来操纵数据,实际上这解锁了使用支持ZMQ集成的非JRE语言编写控制器应用程序的功能,从这个角度来说,它开创了一套全新的开发人员参与项目的能力。
总体而言,Carbon提供更高的稳定性,安全性和增强的网络可编程性。这些基础工作将能够促进在下一个版本Nitrogen中实现Karaf升级,服务激活大大稳定且能够更好地进行测试,以确保更加一致和友好的运营经验。增加的新功能能够帮助与控制器进行通信、导出数据,并且能够更好地配置ODL。