QA

Q1. What do we mean by dynamic evaluation of YANG at run-time?
Q2. Where is MD-SAL persistent store created?
Q3. Data defined in YANG is stored in MD-SAL datastore?
Q4. Which data is stored in MD-SAL config datastore and operational datastore?
Q5. What really is the difference between AD-SAL REST and MD-SAL RESTCONF?
Q6. What is a Container & Multi Tenancy?
Q7. What happens when OpenDaylight Controller is started?
Q8. What is enunciate.xml used for?
Q9. What is the location of local repository on my windows machine?
Q10. Which all Java interfaces gets created corresponding to YANG Module?
Q11. What does the current OpenDaylight’s Netconf Protocol Plugin support?
Q12. How does MD-SAL identify to which southbound plugin, it has to route the request for flow provisioning?
Q13. What is the RESTCONF API to access nodes in opendaylight inventory?
Q14. What is the RESTCONF API to access information of a particular node in opendaylight inventory?
Q15. What is the RESTCONF API to access opendaylight topology information?
Q16. How are OpenDaylight, Restconf, Netconf & Yang inter-related?
Q17. What to do if your corporate firewall blocks Gerrit’s default ssh port (29418)?

Q1. What do we mean by dynamic evaluation of YANG at run-time?

A. When ODL loads a bundle it searches that bundle (JAR) for files that end in “*.yang”. For each YANG file found it processes that file and builds several things dynamically including the structures to expose that as a RESTCONF compliant YANG interface. It also uses JavaAssist to dynamically create and compile classes that are used to marshal the YANG objects between POJOs and a XML/JSON representation. Lastly it maintains information based on the yang to translate between what ODL calls a binding aware class (POJO) and RPC (Java method) and binding independent implementations of the RPCs (such as you might find implemented on a router that is based on NETCONF).

Q2. Where is MD-SAL persistent store created?

A. Currently it is in memory, so you lose it when the controller restarts.

Right now, we have more of a real-time, consistent key-value store which is provided through the clustering services API and backed by Infinispan. Refer – https://lists.opendaylight.org/pipermail/controller-dev/2013-July/000789.html

For high level overview of Model-Driven SAL Datastore – refer https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:DOM_DataStore

From data model perspective – refer – https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Model_Reference

Q3. Data defined in YANG is stored in MD-SAL datastore?

A. YANG defines “classes” not instances of classes. The instance data is stored in the datastore. So YANG is basically a schema that defines how data will be stored in MD-SAL data store and what operations can be performed on this data e.g. Create/Retrieve/Update/Delete (CRUD).

Q4. Which data is stored in MD-SAL config datastore and operational datastore?

A. The config store is where “requests” are stored and the operational store is where “network state as discovered from the network” is stored. So Flows are requested by being placed in the config store, but after they are configured on the NE and ODL “discovers” them that data is put in the operational store.

Q5. What really is the difference between AD-SAL REST and MD-SAL RESTCONF?

A. With AD-SAL, providers and consumers were essentially hard wired, any REST interface was manually defined, and service interfaces / data had to be manually written. With MD-SAL this is essentially driven by the YANG model either through code generation at compile time or dynamic evaluation of YANG at run-time. Additionally with the MD-SAL model service lookup was implemented so that it wasn’t hardwired in ODL which consumers were connected to which producers.

REST:

PUT http://<controllerIP>:8080/controller/nb/v2/ping/127.0.0.1

PUT http://localhost:8080/controller/nb/v2/ping/127.0.0.1

RESTCONF:

PUT /restconf/config/<identifier> [identifier points to a data node to be stored]

PUT http://<controllerIP>:8080/restconf/config/module1:foo/bar

GET /restconf/operational/<identifier>

Q6. What is a Container & Multi Tenancy?

A. Refer to this link – https://lists.opendaylight.org/pipermail/controller-dev/2013-April/000125.html

Q7. What happens when OpenDaylight Controller is started?

A. Following are the key components which are started:

  • OSGI framework is launched and OSGI bundles are loaded
  • Web Server Interface for REST APIs
  • Key-value store (Infinispan) is clustered and hence communications channels for those are started [Config and Operational datastores are in-memory are different from Infinispan caches]
  • Openflow interface communication channel is started
  • Since, ODL is event-driven reactor from the network perspective, there are scheduled activities which run constantly but start executing their cycles upon receiving events from network. Following are some of them
    • Periodic stats collector – which periodically collects statistics from switches
    • LLDP sender/receiver – so that topological changes could be handled in timely manner
    • Host tracking

Q8. What is enunciate.xml used for?

A. It describes where the APIs should be mounted on the REST path.

Q9. What is the location of local repository on my windows machine?

A. It is located under C:\Users\<user-name>\.m2.

Q10. Which all Java interfaces gets created corresponding to YANG Module?

A. When a YANG module is converted to Java Source Code, following three interfaces gets created:

  1. Data Interface :  contains getter methods for top level nodes defined in module. [extends opendaylight's DataRoot interface]
  2. Service Interface: contains method declarations for RPC contracts defined by all rpc statements in module. [extends opendaylight's RpcService interface]
  3. Listener Interface: contains method declarations for notification handlers defined by all notification statements in module. [extends opendaylight's NotificationListener interface]

Q11. What does the current OpenDaylight’s Netconf Protocol Plugin support?

A. As of date (9/04/2014), odl’s netconf protocol plugin

  1. Connecting to devices that support netconf 1.0/1.1
  2. Loading YANG files from the device to represent its data (for devices do not support ietf monitoring, no yang files are loaded. For this there is a bug in opendaylight – Bug 628)
  3. Supports netconf over ssh, chunking and eom framing as defined in https://tools.ietf.org/html/rfc6242#section-4.1

Q12. How does MD-SAL identify to which southbound plugin, it has to route the request for flow provisioning?

A. Refer this link.

Q13. What is the RESTCONF API to access nodes in opendaylight inventory?

A. http://<controller-ip>:8080/restconf/operational/opendaylight-inventory:nodes/

Q14. What is the RESTCONF API to access information of a particular node in opendaylight inventory?

A. http://<controller-ip>:8080/restconf/operational/opendaylight-inventory:nodes/node/id [replace id by the actual node id]

Q15. What is the RESTCONF API to access opendaylight topology information?

A. http://<controller-ip>:8080/restconf/operational/network-topology:network-topology/topology/flow:1

Q16. How are OpenDaylight, Restconf, Netconf & Yang inter-related?

A. Refer this link.

Q17. What to do if your corporate firewall blocks Gerrit’s default ssh port (29418)?

A. Refer this link.