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)?
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).
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
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).
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.
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.
PUT /restconf/config/<identifier> [identifier points to a data node to be stored]
A. Refer to this link – https://lists.opendaylight.org/pipermail/controller-dev/2013-April/000125.html
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
A. It describes where the APIs should be mounted on the REST path.
A. It is located under C:\Users\<user-name>\.m2.
A. When a YANG module is converted to Java Source Code, following three interfaces gets created:
- Data Interface : contains getter methods for top level nodes defined in module. [extends opendaylight’s DataRoot interface]
- Service Interface: contains method declarations for RPC contracts defined by all rpc statements in module. [extends opendaylight’s RpcService interface]
- Listener Interface: contains method declarations for notification handlers defined by all notification statements in module. [extends opendaylight’s NotificationListener interface]
A. As of date (9/04/2014), odl’s netconf protocol plugin
- Connecting to devices that support netconf 1.0/1.1
- 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)
- Supports netconf over ssh, chunking and eom framing as defined in https://tools.ietf.org/html/rfc6242#section-4.1
A. Refer this link.
A. http://<controller-ip>:8080/restconf/operational/opendaylight-inventory:nodes/node/id [replace id by the actual node id]
A. Refer this link.
A. Refer this link.