An excerpt from chat with Tomas Olvecky:
Q.YANG is a modeling language written to support netconf based devices. But in opendaylight we are using it to describe the structure of data provided by controller components. Well there are couple of tutorials on internet which makes me believe that netconf and yang are inseparable. Please throw some light on it.
A. In opendaylight, yang is being used as a general purpose modeling language. There are two code generators that drive this:
1) MD-SAL Generator
It uses Restconf i.e provides a restconf endpoint. MD-SAL generator is used as typesafe layer to ease development of datastore related components so that when component A wants to communicate with B over md-sal (which can be local or remote call), it does not have to care about (de)serialization. MD-SAL as whole is driven by yang models, basically using it as validation, similar to xsd.
2) Config Generator
It uses Netconf i.e. provides a netconf endpoint. Config subsystem also uses models to generate code. It’s scope is to provide dependency injection and configuration during server runtime. This is somewhat similar to blueprint in OSGi, but externalizes the XML from jar files. So you can connect to running ODL via netconf and push xml that will reconfigure the server. Let’s say you want to mount new netconf/bgp/openflow node, you just connect via netconf and push the change. This is contrary to how blueprint works, because in blueprint you have to edit xml for each bundle, then repackage, then deploy and then start the container. Yang in config subsystem is used mainly to generate config java skeletons, and also as type safe layer, so that netconf client can do partial validation.
Q. It sounds confusing because netconf is more of a southbound protocol and restconf is more of a northbound protocol. Is it correct to say that in md-sal and config context we are using them more generically?
A. Both restconf and netconf are just protocols to get/edit configuration data, operational data, call rpcs and receive notifications. A good analogy for me of md-sal is XML database. Config is more like spring with dynamic reconfiguration. But both can be looked as xml databases. So MD-SAL database is accessible through Restconf and Config subsystem database is accessible through Netconf.
Q. Is there any particular reason we chose config subsystem to implement a netconf server?
A. Netconf server is actually plugable, currently we have only config subsystem bridge & we might have md-sal bridge in future which will allow to access MD-SAL database using Netconf.
References
About use of NETCONF and MD-SAL I have some doubts.
I’m able to connect my devices( that use netopeer for example ) to client netconf of opendaylight
and i have the restconf of my external yang models implemented on my mountpoints.
But is not clear how i can build a MD-SAL that use the netconf functionality of my mountpoints.
Should I make Http rest call inside my MD-SAL? I hope no 🙂 !!
There is a way to connect my NETCONF client, mirror of my mountpoint, inside my MD-SAL?
Thx
Al
Hi Al,
You can communicate with your device from code level using the MountPointService APIs. With this API you can access your device in an “MD-SAL” fashion utilizing a DataBroker, RpcService and even a NotificationService.
There is a nice example for how to do this in coretutorials project (ncmount subproject). Core tutorials can be found here:
https://git.opendaylight.org/gerrit/#/admin/projects/coretutorials
some documentation;
https://wiki.opendaylight.org/view/Controller_Core_Functionality_Tutorials:Tutorials:Netconf_Mount
Maros