Opendaylight notes

odl-notes.txt

1) GettingStarted:Development Environment Setup
https://wiki.opendaylight.org/view/GettingStarted:Development_Environment_Setup#Edit_your_.7E.2F.m2.2Fsettings.xml

GettingStarted:_Eclipse
2) https://wiki.opendaylight.org/view/GettingStarted:_Eclipse


You need to clone and compile in that order:
1. odlparent (git clone https://git.opendaylight.org/gerrit/odlparent)
2. yangtools (git clone https://git.opendaylight.org/gerrit/yangtools)
3. controller (git clone https://git.opendaylight.org/gerrit/controller)

4) Hello world project
https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Startup_Project_Archetype


Mininet

sudo mn --mac --switch=ovsk,protocols=OpenFlow13 --controller=remote,ip=10.0.1.33,port=6653 --topo=tree,2



mvn archetype:generate -DarchetypeGroupId=org.opendaylight.controller -DarchetypeArtifactId=opendaylight-startup-archetype -DarchetypeRepository=http://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/ -DarchetypeCatalog=http://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/archetype-catalog.xml


*-impl.yang, broker/rpcregistry problems:

md-sal-binding:binding-async-data-broker in yang file must be the same of the broker type in "default.config" file

Example: binding:binding-async-data-broker / binding:binding-rpc-registry
Link: https://lists.opendaylight.org/pipermail/controller-dev/2014-July/005318.html


Create a new bundle manually
	- Copy and modify pom.xml from "consumer project" from Gabriel's repository
	- Use the same version (0.3.0-SNAPSHOT - > Lithium)
	- Wire the new bundle to the project:
		1) pom.xml file (root project): add module after <module>impl</module>
		2) (*-features/src/main/features/features.xml) : <bundle>mvn:org.opendaylight.controller.office.api/${project.version}</bundle>
		Example: the features file is syntaxed as follow: <bundle>mvn:GROUPID/ARTIFACTID/VERSION</bundle>

MD-SAL currently provides infrastructure services for:

Data Store
RPC / Service routing
Notification subscription and publish services


*Important generated classes:

toaster.yang - This file defines the north bound data model. Specifically, it defines the abstraction of a toaster that is visible to north-bound clients (e.g. the restconf API).

toaster-provider-impl.yang - This file defines an implementation of the toaster service and the services it needs from the MD-SAL framework, e.g. the data-broker, which is used to store the operational data of the toaster.

Toaster - an interface that represents the toaster container with methods to obtain the leaf node data.

ToasterData - an interface that represents the top-level toaster module with one method getToaster() that returns the singleton toaster instance.

WheatBread, WhiteBread, etc' - abstract classes that represent the various toast types.

$YangModelBindingProvider, $YangModuleInfoImpl - these are used internally by MD-SAL to wire the toaster module for use. More on this later.

ToasterProviderModule - concrete class whose createInstance() method provides the OpendaylightToaster instance.

ToasterProviderModuleFactory - concrete class instantiated internally by MD-SAL that creates 
ToasterProviderModule instances.

ToasterService - an interface that extends RpcService and defines the RPC methods corresponding to the yang data model.

MakeToastInput - an interface defining a DTO providing the input parameters for the make-toast call.

MakeToastInputBuilder - a concrete class for creating MakeToastInput instances.

ToasterProviderRuntimeMXBean - JMX bean interface that defines the getToastsMade() method to provide access to the toasts-made attribute and the clearToastsMade() RPC method.

ToasterProviderRuntimeRegistration - concrete class that wraps a ToasterProviderRuntimeMXBean registration.

ToasterProviderRuntimeRegistrator - concrete class that registers a ToasterProviderRuntimeMXBean implementation with the MD-SAL.