Reference Guide
Table Of Contents
- 1 Introduction
- 2 Establishing Your Test and Development Environments
- 3 Developing Applications
- Introduction
- Authentication
- REST API
- Audit Logging
- Alert Logging
- Configuration
- High Availability
- OpenFlow
- Metrics Framework
- GUI
- SKI Framework - Overview
- SKI Framework - Navigation Tree
- SKI Framework - Hash Navigation
- SKI Framework - View Life-Cycle
- SKI Framework - Live Reference Application
- UI Extension
- Introduction
- Controller Teaming
- Distributed Coordination Service
- Persistence
- Backup and Restore
- Device Driver Framework
- 4 Application Security
- 5 Including Debian Packages with Applications
- 6 Sample Application
- Application Description
- Creating Application Development Workspace
- Application Generator (Automatic Workspace Creation)
- Creating Eclipse Projects
- Updating Project Dependencies
- Building the Application
- Installing the Application
- Application Code
- 7 Testing Applications
- 8 Built-In Applications
- Appendix A
- Appendix B
- Bibliography
Controller Teaming
Teaming Configuration Service
The Teaming Configuration Service provides REST interfaces (/team) that can be used to set up a
team of controllers. Without team configuration, controller nodes will bootstrap in standalone
mode. As the teaming is configured, identified nodes form a cluster and the controller Applications
can communicate across the cluster using Coordination Service interfaces.
The following curl command is used to get the current team configuration. 192.168.66.1 is the IP
address of one of the teamed controllers.
curl --noproxy 192.168.66.1 --header "X-Auth-Token:
19a4b8a048ef4965882eb8c570292bcd" --request GET --url
https://192.168.66.1:8443/sdn/v2.0/team -ksS
For team creation help and other configuration commands please refer to HP VAN SDN Controller
Administrator Guide [29].
Distributed Coordination Service
Distributed Coordination Service provides the building blocks to achieve high availability in the HP
VAN SDN Controller environment. This service can be retrieved from the Teaming Service. An
example java application that makes use of different functionalities of the Coordination Service is
described in the subsequent sections.
Distributed Coordination Service includes:
•
Publish Subscribe Service
•
Distributed Maps
•
Distributed Locks
Serialization
It is required to register a Serializer for each distributable object because of the multiple class
loaders approach followed by OSGi. No serializer is required for the following types: Byte,
Boolean, Character, Short, Integer, Long, Float, Double, byte[], char[], short[], int[], long[], float[],
double[], String.
If a distributable object implements Serializable, Distributable must be found before Serializable
in the class hierarchy going from the distributable object to its super classes. Unfortunately the
order matters: The class hierarchy is analyzed when registering the serializer. If Serializable is
found before Distributable an exception is thrown with a message describing this restriction.
Example of distributable object declarations:
67