The purpose of the application subsystem is to facilitate easy software delivery and management across all ONOS instances in a cluster. The subsystem uses ONOS eventually consistent map and the inter-node communication mechanism to fully replicate the inventory of applications across the entire ONOS cluster. To install and ignite software as sets of OSGi bundles, the subsystem relies on the underlying Apache Karaf feature mechanism.
All builtin sample and test applications provided by ONOS are now delivered using this mechanism and come pre-installed - although not activated - as part of the standard ONOS distribution. This includes any providers, such as OpenFlow providers. In this way, all optional software components can be installed into and withdrawn from ONOS without the need to rebuild, or even to reconfigure ONOS itself.
Applications can be uploaded or defined in ONOS using either a plain app.xml file or a package file (ZIP) containing an app.xml file, any OSGi bundles, or feature definition file. The app.xml file specifies the following attributes:
The following is an example of of the ONOS OnePing sample application app.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<app name="org.onosproject.oneping" origin="ON.Lab" version="1.2.0"
featuresRepo="mvn:org.onosproject/oneping-app-features/1.2.0-SNAPSHOT/xml/features"
features="oneping-app,onos-app-tvue">
<description>One-Ping-Only sample application!</description>
</app> |
If an application needs to deliver artifacts, such as feature definitions or OSGi bundles which are not available in a public object repository such as Maven central, it can be packaged into an application package file, which is a ZIP file that contains the above app.xml descriptor as well as any other artifacts organized using repository structure hierarchy. The following describes the structure of the application package file:
Currently, application package files can be produced using maven-assembly-plugin, but in the near future onos-maven-plugin will offer capability to easily produce properly structured application package files.
Administrators can interact with the inventory of applications using the following console commands:
Orchestration systems and tools can use the REST API to interact with the application subsystem either directly, or using the onos-app shell utility, which uses the REST API and has the following usage:
Example will come soon.
The following list describes the inventory of all builtin sample and test applications: