Difference between revisions of "Honeycomb/Releases/1609/Developing Honeycomb Plugins"

From fd.io
Jump to: navigation, search
(Honeycomb plugin development tutorial)
(Adding notification)
Line 93: Line 93:
  
 
==== Adding notification ====
 
==== Adding notification ====
In case
+
No notification producer is generated by the archetype, but it is pretty straightforward to add one.
 +
 
 +
First, the notification has to be defined in YANG (sample-plugin-api/src/main/yang/sample-plugin.yang) e.g.
 +
 
 +
  notification sample-notification {
 +
      leaf content {
 +
          type string;
 +
      }
 +
  }
  
 
==== Creating custom agent distribution ====
 
==== Creating custom agent distribution ====

Revision as of 10:32, 2 September 2016

Honeycomb plugin development tutorial

Honeycomb plugin development guide for 16.09 Honeycomb release.

Plugin overview

Honeycomb provides a framework for plugins to participate in the data handling. The plugins use YANG modeling language to describe what:

  • data they can handle (Create, Read, Update, Delete operations)
  • notifications do they emit
  • RPCs are not supported

A plugin usually consists of:

  • YANG models - These models contain data and notification definitions that are implemented by the plugin. ODL's Yangtools project is used to generate Java APIs from those models (called Binding Aware APIs in ODL) and are later used in the translation code.
  • Set of readers - Readers provide operational/state data from plugin or its underlying layer. This means that operational/state data is current state of the plugin or its underlying layer. Readers return these operational data by e.g. reading from underlying layer and transforming it into YANG modeled data.
  • Set of writers - Writers handle configuration data for the plugin or its underlying layer This means that configuration data is the intent being sent to Honeycomb, that should be passed to plugins or their underlying layers. Writers handle these configuration data by transforming YANG modeled data into e.g. underlying layer calls.
  • Set of initializers - Initializers are invoked right after Honeycomb starts. The gould here is to read current operational/state data of the plugin or its underlying layer and then transform the operational data into configuration data. This enables reconciliation in cases when Honeycomb looses it's persisted data, or is started fresh while the underlying layer already contains some configuration that is manifested as operational/state data
  • Plugin configuration - Usually configuration in json format + it's Java equivalent.
  • Set of notification producers - If there are any notifications, the producers transform the data into YANG model notifications and emit them.
  • Module - Small class instantiating & exposing plugin's components

What's good to add:

  • Unit tests
  • Documentation
  • Sample REST or NETCONF requests

Prerequisites

Make sure to check Honeycomb/Setting_Up_Your_Dev_Environment page to properly setup the environment.

Developing generic plugins

Since Honeycomb is a generic agent. Any plugin (translation code) can be injected into the framework, creating a custom agent providing RESTCONF/NETCONF northbound interfaces out-of-box.

Developing plugin code

Honeycomb provides a maven archetype to generate a plugin skeleton. To use that archetype, run maven:

 mvn -X archetype:generate -DarchetypeGroupId=io.fd.honeycomb.tools -DarchetypeArtifactId=honeycomb-plugin-archetype -DarchetypeVersion=1.16.9-SNAPSHOT

Fill in the parameters e.g.

 groupId: io.fd.honeycomb.tutorial
 artifactId: sample-plugin
 version: 1.16.9-SNAPSHOT
 package: io.fd.honeycomb.tutorial

And following structure should be created:

 sample-plugin/
 ├── pom.xml
 ├── sample-plugin-api
 │   ├── pom.xml
 │   └── src
 │       └── main
 │           ├── java
 │           └── yang
 │               └── sample-plugin.yang
 └── sample-plugin-impl
     ├── pom.xml
     ├── Readme.adoc
     └── src
         ├── main
         │   └── java
         │       └── io
         │           └── fd
         │               └── honeycomb
         │                   └── tutorial
         │                       ├── CrudService.java
         │                       ├── ElementCrudService.java
         │                       ├── init
         │                       │   └── ConfigDataInitializer.java
         │                       ├── ModuleConfiguration.java
         │                       ├── Module.java
         │                       ├── read
         │                       │   ├── ElementStateCustomizer.java
         │                       │   └── ModuleStateReaderFactory.java
         │                       └── write
         │                           ├── ElementCustomizer.java
         │                           └── ModuleWriterFactory.java
         └── test
             └── java
 

There are 2 modules:

  • sample-plugin-api - Contains YANG models and generates Java APIs from the models.
  • sample-plugin-impl - Contains: Readers, Writers, Initializers, Notification producers (not yet), Configuration and Wiring.

There is plenty of comments within the code, so its is advised to import the code into an IDE and take a look around.

The archetype generates a plugin that is fully working right from the start. Since it contains all the components necessary, works on a sample yang model and provides some sample values.

Building the code

To build the code, just execute maven:

 mvn clean install

And that's it. This is a working Honeycomb plugin.

Adding notification

No notification producer is generated by the archetype, but it is pretty straightforward to add one.

First, the notification has to be defined in YANG (sample-plugin-api/src/main/yang/sample-plugin.yang) e.g.

 notification sample-notification {
     leaf content {
         type string;
     }
 }

Creating custom agent distribution

Adding existing plugins to the mix

Verifying agent

Full working example

Developing plugins for VPP

Honeycomb's primary use case is to provide an agent for VPP. There already are some plugins that provide the translation code for VPP, but there are still APIs that are not covered. In this section, a sample Honeycomb plugin will be created communicating with VPP.

Developing plugin code

Bootstrapping Honeycomb plugin

Creating custom agent distribution

Adding existing plugins to the mix

Verifying agent

Full working example