*.ipr
*.iws
*~
+.DS_Store
+
+# Python
+.tox/
+__pycache__/
+*.pyc
path = docs/submodules/releng/builder
url = ../releng/builder
branch = master
+[submodule "docs/submodules/integration/test"]
+ path = docs/submodules/integration/test
+ url = ../integration/test/
+ branch = master
_build/
+_static/integration/robot
--- /dev/null
+#!/bin/bash
+
+ROBOT_DIR=`pwd`/_static/integration/robot
+
+mkdir -p $ROBOT_DIR
+cd submodules/integration/test/csit/libraries
+for f in *.robot; do python -m robot.libdoc $f $ROBOT_DIR/$f.html; done
+for f in *.py; do python -m robot.libdoc $f $ROBOT_DIR/$f.html; done
+cd $ROBOT_DIR/
+for f in *.html; do sed -i 's/black/orange/; s/white/black/; s/^<body>/<body><img src="..\/..\/odl.png">/' $f; done
# The name of an image file (relative to this directory) to place at the top
# of the sidebar.
-#html_logo = None
+html_logo = '_static/odl.png'
# The name of an image file (relative to this directory) to use as a favicon of
# the docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
# The '#' in the path makes sphinx think it's an anchor
'https://git.opendaylight.org/gerrit/#/admin/projects/releng/builder',
]
+
+# Build integration stuff
+import subprocess
+
+subprocess.call(["./build-integration-robot-libdoc.sh"])
+
--- /dev/null
+.. _documentation-guide:
+
+Documentation Guide
+===================
+
+This guide provides details on how to contribute to the documetantion of
+Spectrometer. The style guide we follow for documentation is the python
+documentation style guide. See:
+
+ https://docs.python.org/devguide/documenting.html
+
+To build and review the documentation locally you first require to have
+installed locally:
+
+* python
+* python-tox
+
+Which both should be available in most distribution's package managers.
+
+Then simply run tox and open the html produced via your favourite web browser.
+
+.. code-block:: bash
+
+ tox -edocs
+ firefox docs/_build/html/index.html
--- /dev/null
+Setting Up Clustering
+=====================
+
+Clustering Overview
+-------------------
+
+Clustering is a mechanism that enables multiple processes and programs to work
+together as one entity. For example, when you search for something on
+google.com, it may seem like your search request is processed by only one web
+server. In reality, your search request is processed by may web servers
+connected in a cluster. Similarly, you can have multiple instances of
+OpenDaylight working together as one entity.
+
+Advantages of clustering are:
+
+* Scaling: If you have multiple instances of OpenDaylight running, you can
+ potentially do more work and store more data than you could with only one
+ instance. You can also break up your data into smaller chunks (shards) and
+ either distribute that data across the cluster or perform certain operations
+ on certain members of the cluster.
+* High Availability: If you have multiple instances of OpenDaylight running and
+ one of them crashes, you will still have the other instances working and
+ available.
+* Data Persistence: You will not lose any data stored in OpenDaylight after a
+ manual restart or a crash.
+
+The following sections describe how to set up clustering on both individual and
+multiple OpenDaylight instances.
+
+Multiple Node Clustering
+------------------------
+
+The following sections describe how to set up multiple node clusters in OpenDaylight.
+
+Deployment Considerations
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To implement clustering, the deployment considerations are as follows:
+
+* To set up a cluster with multiple nodes, we recommend that you use a minimum
+ of three machines. You can set up a cluster with just two nodes. However, if
+ one of the two nodes fail, the cluster will not be operational.
+
+ .. note:: This is because clustering in OpenDaylight requires a majority of the
+ nodes to be up and one node cannot be a majority of two nodes.
+
+* Every device that belongs to a cluster needs to have an identifier.
+ OpenDaylight uses the node's ``role`` for this purpose. After you define the
+ first node's role as *member-1* in the ``akka.conf`` file, OpenDaylight uses
+ *member-1* to identify that node.
+
+* Data shards are used to contain all or a certain segment of a OpenDaylight's
+ MD-SAL datastore. For example, one shard can contain all the inventory data
+ while another shard contains all of the topology data.
+
+ If you do not specify a module in the ``modules.conf`` file and do not specify
+ a shard in ``module-shards.conf``, then (by default) all the data is placed in
+ the default shard (which must also be defined in ``module-shards.conf`` file).
+ Each shard has replicas configured. You can specify the details of where the
+ replicas reside in ``module-shards.conf`` file.
+
+* If you have a three node cluster and would like to be able to tolerate any
+ single node crashing, a replica of every defined data shard must be running
+ on all three cluster nodes.
+
+ .. note:: This is because OpenDaylight's clustering implementation requires a
+ majority of the defined shard replicas to be running in order to
+ function. If you define data shard replicas on two of the cluster nodes
+ and one of those nodes goes down, the corresponding data shards will not
+ function.
+
+* If you have a three node cluster and have defined replicas for a data shard
+ on each of those nodes, that shard will still function even if only two of
+ the cluster nodes are running. Note that if one of those remaining two nodes
+ goes down, the shard will not be operational.
+
+* It is recommended that you have multiple seed nodes configured. After a
+ cluster member is started, it sends a message to all of its seed nodes.
+ The cluster member then sends a join command to the first seed node that
+ responds. If none of its seed nodes reply, the cluster member repeats this
+ process until it successfully establishes a connection or it is shut down.
+
+* After a node is unreachable, it remains down for configurable period of time
+ (10 seconds, by default). Once a node goes down, you need to restart it so
+ that it can rejoin the cluster. Once a restarted node joins a cluster, it
+ will synchronize with the lead node automatically.
+
+Setting Up a Multiple Node Cluster
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To run OpenDaylight in a three node cluster, perform the following:
+
+First, determine the three machines that will make up the cluster. After that,
+do the following on each machine:
+
+#. Copy the OpenDaylight distribution zip file to the machine.
+#. Unzip the distribution.
+#. Open the following .conf files:
+
+ * configuration/initial/akka.conf
+ * configuration/initial/module-shards.conf
+
+#. In each configuration file, make the following changes:
+
+ Find every instance of the following lines and replace _127.0.0.1_ with the
+ hostname or IP address of the machine on which this file resides and
+ OpenDaylight will run::
+
+ netty.tcp {
+ hostname = "127.0.0.1"
+
+ .. note:: The value you need to specify will be different for each node in the
+ cluster.
+
+#. Find the following lines and replace _127.0.0.1_ with the hostname or IP
+ address of any of the machines that will be part of the cluster::
+
+ cluster {
+ seed-nodes = ["akka.tcp://opendaylight-cluster-data@127.0.0.1:2550"]
+
+#. Find the following section and specify the role for each member node. Here
+ we assign the first node with the *member-1* role, the second node with the
+ *member-2* role, and the third node with the *member-3* role::
+
+ roles = [
+ "member-1"
+ ]
+
+ .. note:: This step should use a different role on each node.
+
+#. Open the configuration/initial/module-shards.conf file and update the
+ replicas so that each shard is replicated to all three nodes::
+
+ replicas = [
+ "member-1",
+ "member-2",
+ "member-3"
+ ]
+
+ For reference, view a sample config files <<_sample_config_files,below>>.
+
+#. Move into the +<karaf-distribution-directory>/bin+ directory.
+#. Run the following command::
+
+ JAVA_MAX_MEM=4G JAVA_MAX_PERM_MEM=512m ./karaf
+
+#. Enable clustering by running the following command at the Karaf command line::
+
+ feature:install odl-mdsal-clustering
+
+OpenDaylight should now be running in a three node cluster. You can use any of
+the three member nodes to access the data residing in the datastore.
+
+Sample Config Files
+"""""""""""""""""""
+
+Sample ``akka.conf`` file::
+
+ odl-cluster-data {
+ bounded-mailbox {
+ mailbox-type = "org.opendaylight.controller.cluster.common.actor.MeteredBoundedMailbox"
+ mailbox-capacity = 1000
+ mailbox-push-timeout-time = 100ms
+ }
+
+ metric-capture-enabled = true
+
+ akka {
+ loglevel = "DEBUG"
+ loggers = ["akka.event.slf4j.Slf4jLogger"]
+
+ actor {
+
+ provider = "akka.cluster.ClusterActorRefProvider"
+ serializers {
+ java = "akka.serialization.JavaSerializer"
+ proto = "akka.remote.serialization.ProtobufSerializer"
+ }
+
+ serialization-bindings {
+ "com.google.protobuf.Message" = proto
+
+ }
+ }
+ remote {
+ log-remote-lifecycle-events = off
+ netty.tcp {
+ hostname = "10.194.189.96"
+ port = 2550
+ maximum-frame-size = 419430400
+ send-buffer-size = 52428800
+ receive-buffer-size = 52428800
+ }
+ }
+
+ cluster {
+ seed-nodes = ["akka.tcp://opendaylight-cluster-data@10.194.189.96:2550"]
+
+ auto-down-unreachable-after = 10s
+
+ roles = [
+ "member-1"
+ ]
+
+ }
+ }
+ }
+
+ odl-cluster-rpc {
+ bounded-mailbox {
+ mailbox-type = "org.opendaylight.controller.cluster.common.actor.MeteredBoundedMailbox"
+ mailbox-capacity = 1000
+ mailbox-push-timeout-time = 100ms
+ }
+
+ metric-capture-enabled = true
+
+ akka {
+ loglevel = "INFO"
+ loggers = ["akka.event.slf4j.Slf4jLogger"]
+
+ actor {
+ provider = "akka.cluster.ClusterActorRefProvider"
+
+ }
+ remote {
+ log-remote-lifecycle-events = off
+ netty.tcp {
+ hostname = "10.194.189.96"
+ port = 2551
+ }
+ }
+
+ cluster {
+ seed-nodes = ["akka.tcp://opendaylight-cluster-rpc@10.194.189.96:2551"]
+
+ auto-down-unreachable-after = 10s
+ }
+ }
+ }
+
+Sample ``module-shards.conf`` file::
+
+ module-shards = [
+ {
+ name = "default"
+ shards = [
+ {
+ name="default"
+ replicas = [
+ "member-1",
+ "member-2",
+ "member-3"
+ ]
+ }
+ ]
+ },
+ {
+ name = "topology"
+ shards = [
+ {
+ name="topology"
+ replicas = [
+ "member-1",
+ "member-2",
+ "member-3"
+ ]
+ }
+ ]
+ },
+ {
+ name = "inventory"
+ shards = [
+ {
+ name="inventory"
+ replicas = [
+ "member-1",
+ "member-2",
+ "member-3"
+ ]
+ }
+ ]
+ },
+ {
+ name = "toaster"
+ shards = [
+ {
+ name="toaster"
+ replicas = [
+ "member-1",
+ "member-2",
+ "member-3"
+ ]
+ }
+ ]
+ }
+ ]
+
+Clustering Scripts
+------------------
+
+OpenDaylight includes some scripts to help with the clustering configuration.
+
+.. note::
+
+ Scripts are stored in the OpenDaylight distribution/bin folder, and
+ maintained in the distribution project
+ `repository <https://git.opendaylight.org/gerrit/p/integration/distribution>`_
+ in the folder distribution-karaf/src/main/assembly/bin/.
+
+Configure Cluster Script
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+This script is used to configure the cluster parameters (e.g. akka.conf,
+module-shards.conf) on a member of the controller cluster. The user should
+restart the node to apply the changes.
+
+.. note::
+
+ The script can be used at any time, even before the controller is started
+ for the first time.
+
+Usage::
+
+ bin/configure_cluster.sh <index> <seed_nodes_list>
+
+* index: Integer within 1..N, where N is the number of seed nodes. This indicates
+ which controller node (1..N) is configured by the script.
+* seed_nodes_list: List of seed nodes (IP address), separated by comma or space.
+
+The IP address at the provided index should belong to the member executing
+the script. When running this script on multiple seed nodes, keep the
+seed_node_list the same, and vary the index from 1 through N.
+
+Optionally, shards can be configured in a more granular way by modifying the
+file "custom_shard_configs.txt" in the same folder as this tool. Please see
+that file for more details.
+
+Example::
+
+ bin/configure_cluster.sh 2 192.168.0.1 192.168.0.2 192.168.0.3
+
+The above command will configure the member 2 (IP address 192.168.0.2) of a
+cluster made of 192.168.0.1 192.168.0.2 192.168.0.3.
+
+Set Persistence Script
+^^^^^^^^^^^^^^^^^^^^^^
+
+This script is used to enable or disable the config datastore persistence. The
+default state is enabled but there are cases where persistence may not be
+required or even desired. The user should restart the node to apply the changes.
+
+.. note::
+
+ The script can be used at any time, even before the controller is started
+ for the first time.
+
+Usage::
+
+ bin/set_persistence.sh <on/off>
+
+Example::
+
+ bin/set_persistence.sh off
+
+The above command will disable the config datastore persistence.
--- /dev/null
+OpenDaylight User Interface (DLUX)
+==================================
+
+This section introduces you to the OpenDaylight User Experience (DLUX) application.
+
+Getting Started with DLUX
+-------------------------
+
+DLUX provides a number of different Karaf features, which you can enable and disable separately. In Boron they are:
+
+#. odl-dlux-core
+#. odl-dlux-node
+#. odl-dlux-yangui
+#. odl-dlux-yangvisualizer
+
+Logging In
+----------
+
+To log in to DLUX, after installing the application:
+
+#. Open a browser and enter the login URL http://<your-karaf-ip>:8181/index.html in your browser (Chrome is recommended).
+#. Login to the application with your username and password credentials.
+
+.. note:: OpenDaylight's default credentials are *admin* for both the username and password.
+
+Working with DLUX
+-----------------
+
+After you login to DLUX, if you enable only odl-dlux-core feature, you will see only topology application available in the left pane.
+
+.. note:: To make sure topology displays all the details, enable the odl-l2switch-switch feature in Karaf.
+
+DLUX has other applications such as node, yang UI and those apps won't show up, until you enable their features odl-dlux-node and odl-dlux-yangui respectively in the Karaf distribution.
+
+.. figure:: images/dlux/dlux-login.png
+ :width: 500
+
+ DLUX Modules
+
+.. note:: If you install your application in dlux, they will also show up on the left hand navigation after browser page refresh.
+
+Viewing Network Statistics
+--------------------------
+
+The *Nodes* module on the left pane enables you to view the network statistics and port information for the switches in the network.
+
+To use the *Nodes* module:
+
+#. Select *Nodes* on the left pane. The right pane displays atable that lists all the nodes, node connectors and the statistics.
+#. Enter a node ID in the *Search Nodes* tab to search by node connectors.
+#. Click on the *Node Connector* number to view details such as port ID, port name, number of ports per switch, MAC Address, and so on.
+#. Click *Flows* in the Statistics column to view Flow Table Statistics for the particular node like table ID, packet match, active flows and so on.
+#. Click *Node Connectors* to view Node Connector Statistics for the particular node ID.
+
+Viewing Network Topology
+------------------------
+
+The Topology tab displays a graphical representation of network topology created.
+
+.. note:: DLUX does not allow for editing or adding topology information. The topology is generated and edited in other modules, e.g., the OpenFlow plugin. OpenDaylight stores this information in the MD-SAL datastore where DLUX can read and display it.
+
+To view network topology:
+
+#. Select *Topology* on the left pane. You will view the graphical representation on the right pane. In the diagram blue boxes represent the switches, the black represents the hosts available, and lines represents how the switches and hosts are connected.
+#. Hover your mouse on hosts, links, or switches to view source and destination ports.
+#. Zoom in and zoom out using mouse scroll to verify topology for larger topologies.
+
+.. figure:: images/dlux/dlux-topology.png
+ :width: 500
+
+ Topology Module
+
+Interacting with the YANG-based MD-SAL datastore
+------------------------------------------------
+
+The *Yang UI* module enables you to interact with the YANG-based MD-SAL datastore. For more information about YANG and how it interacts with the MD-SAL datastore, see the *Controller* and *YANG Tools* section of the *OpenDaylight Developer Guide*.
+
+.. figure:: images/dlux/dlux-yang-ui-screen.png
+ :width: 500
+
+ Yang UI
+
+To use Yang UI:
+
+#. Select *Yang UI* on the left pane. The right pane is divided in two parts.
+#. The top part displays a tree of APIs, subAPIs, and buttons to call possible functions (GET, POST, PUT, and DELETE).
+
+ .. note:: Not every subAPI can call every function. For example, subAPIs in the *operational* store have GET functionality only.
+
+ Inputs can be filled from OpenDaylight when existing data from OpenDaylight is displayed or can be filled by user on the page and sent to OpenDaylight.
+
+ Buttons under the API tree are variable. It depends on subAPI specifications. Common buttons are:
+
+ * GET to get data from OpenDaylight,
+ * PUT and POST for sending data to OpenDaylight for saving
+ * DELETE for sending data to OpenDaylight for deleting.
+
+ You must specify the xpath for all these operations. This path is displayed in the same row before buttons and it may include text inputs for specific path element identifiers.
+
+ .. figure:: images/dlux/dlux-yang-api-specification.png
+ :width: 500
+
+ Yang API Specification
+
+#. The bottom part of the right pane displays inputs according to the chosen subAPI.
+
+ * Lists are handled as a special case. For example, a device can store multiple flows. In this case "flow" is name of the list and every list element is identified by a unique key value. Elements of a list can, in turn, contain other lists.
+ * In Yang UI, each list element is rendered with the name of the list it belongs to, its key, its value, and a button for removing it from the list.
+
+ .. figure:: images/dlux/dlux-yang-sub-api-screen.png
+ :width: 500
+
+ Yang UI API Specification
+
+#. After filling in the relevant inputs, click the *Show Preview* button under the API tree to display request that will be sent to OpenDaylight.
+ A pane is displayed on the right side with text of request when some input is filled.
+
+Displaying Topology on the Yang UI
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To display topology:
+
+#. Select subAPI network-topology <topology revision number> == > operational == > network-topology.
+#. Get data from OpenDaylight by clicking on the "GET" button.
+#. Click *Display Topology*.
+
+.. figure:: images/dlux/dlux-yang-topology.png
+ :width: 500
+
+ DLUX Yang Topology
+
+Configuring List Elements on the Yang UI
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Lists in Yang UI are displayed as trees. To expand or collapse a list, click the arrow before name of the list. To configure list elements in Yang UI:
+
+#. To add a new list element with empty inputs use the plus icon-button **+** that is provided after list name.
+#. To remove several list elements, use the *X* button that is provided after every list element.
+
+ .. figure:: images/dlux/dlux-yang-list-elements.png
+ :width: 500
+
+ DLUX List Elements
+
+#. In the YANG-based data store all elements of a list must have a unique key. If you try to assign two or more elements the same key, a warning icon *!* is displayed near their name buttons.
+
+ .. figure:: images/dlux/dlux-yang-list-warning.png
+ :width: 500
+
+ DLUX List Warnings
+
+#. When the list contains at least one list element, after the *+* icon, there are buttons to select each individual list element. You can choose one of them by clicking on it. In addition, to the right of the list name, there is a button which will display a vertically scrollable pane with all the list elements.
+
+ .. figure:: images/dlux/dlux-yang-list-button1.png
+ :width: 500
+
+ DLUX List Button
--- /dev/null
+Common OpenDaylight Features
+============================
+
+.. toctree::
+ :maxdepth: 1
+
+ dlux
+ clustering
+ xsql
+ version
--- /dev/null
+OpenDaylight Version
+====================
+
+Overview
+--------
+
+This feature allows NETCONF/RESTCONF users to determine the version of
+OpenDaylight they are communicating with.
+
+Install the Version Feature
+---------------------------
+
+Follow these steps to install the version feature:
+
+#. Navigate to the directory in which you installed OpenDaylight
+#. Start Karaf::
+
+ ./bin/karaf
+
+#. Install Version feature::
+
+ feature:install odl-distribution-version
+
+.. note:: For RESTCONF access, it is recommended to install odl-restconf
+ and odl-netconf-connector-ssh.
+
+Version Feature Usage
+---------------------
+
+Example of RESTCONF request using curl from bash::
+
+ $ curl -u 'admin:admin' localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/odl-distribution-version:odl-version/odl-distribution-version
+
+Example response (formatted)::
+
+ {
+ "module": [
+ {
+ "type": "odl-distribution-version:odl-version",
+ "name": "odl-distribution-version",
+ "odl-distribution-version:version": "0.5.0-SNAPSHOT"
+ }
+ ]
+ }
--- /dev/null
+Running XSQL Console Commands and Queries
+=========================================
+
+XSQL Overview
+-------------
+
+XSQL is an XML-based query language that describes simple stored procedures
+which parse XML data, query or update database tables, and compose XML output.
+XSQL allows you to query tree models like a sequential database. For example,
+you could run a query that lists all of the ports configured on a particular
+module and their attributes.
+
+The following sections cover the XSQL installation process, supported XSQL
+commands, and the way to structure queries.
+
+Installing XSQL
+---------------
+
+To run commands from the XSQL console, you must first install XSQL on your
+system:
+
+#. Navigate to the directory in which you unzipped OpenDaylight
+#. Start Karaf::
+
+ ./bin/karaf
+
+#. Install XSQL::
+
+ feature:install odl-mdsal-xsql
+
+XSQL Console Commands
+---------------------
+
+To enter a command in the XSQL console, structure the command as follows::
+
+ odl:xsql _<XSQL command>_
+
+The following table describes the commands supported in this OpenDaylight
+release.
+
+Supported XSQL Console Commands
+
++-----------------+-------------------------------------------------------------------------------+
+| *Command* | *Description* |
++=================+===============================================================================+
+| r | Repeats the last command you executed. |
++-----------------+-------------------------------------------------------------------------------+
+| list vtables | Lists the schema node containers that are currently installed. Whenever an |
+| | OpenDaylight module is installed, its YANG model is placed in the schema |
+| | context. At that point, the XSQL receives a notification, confirms that the |
+| | module's YANG model resides in the schema context and then maps the model to |
+| | XSQL by setting up the necessary vtables and vfields. This command is useful |
+| | when you need to determine vtable information for a query. |
++-----------------+-------------------------------------------------------------------------------+
+| list vfields | Lists the vfields present in a specific vtable. This command is useful when |
+| *<vtable name>* | you need to determine vfields information for a query. |
++-----------------+-------------------------------------------------------------------------------+
+| jdbc | When the ODL server is behind a firewall, and the JDBC client cannot connect |
+| *<ip address>* | to the JDBC server, run this command to start the client as a server and |
+| | establish a connection. |
++-----------------+-------------------------------------------------------------------------------+
+| exit | Closes the console. |
++-----------------+-------------------------------------------------------------------------------+
+| tocsv | Enables or disables the forwarding of query output as a .csv file. |
++-----------------+-------------------------------------------------------------------------------+
+| filename | Specifies the .tocsv file to which the query data is exported. If you do not |
+| *<filename>* | specify a value for this option when the toccsv option is enabled, the |
+| | filename for the query data file is generated automatically. |
++-----------------+-------------------------------------------------------------------------------+
+
+XSQL Queries
+------------
+
+You can run a query to extract information that meets the criteria you specify
+using the information provided by the *list vtables* and *list vfields*
+_<vtable name>_ commands. Any query you run should be structured as follows:
+
+*select* _<vfields you want to search for, separated by a comma and a space>_
+*from* _<vtables you want to search in, separated by a comma and a space>_
+*where* _<criteria>_ *'*_<criteria operator>_*';*
+
+For example, if you want to search the nodes/node ID field in the
+nodes/node-connector table and find every instance of the Hardware-Address
+object that contains _BA_ in its text string, enter the following query::
+
+ select nodes/node.ID from nodes/node-connector where Hardware-Address like '%BA%';
+
+The following criteria operators are supported:
+
+Supported XSQL Query Criteria Operators
+
++--------------------+----------------------------------------------------------------------+
+| Criteria Operators | Description |
++====================+======================================================================+
+| *=* | Lists results that equal the value you specify. |
++--------------------+----------------------------------------------------------------------+
+| *!=* | Lists results that do not equal the value you specify. |
++--------------------+----------------------------------------------------------------------+
+| *like* | Lists results that contain the substring you specify. For |
+| | example, if you specify *like %BC%*, every string that contains |
+| | that particular substring is displayed. |
++--------------------+----------------------------------------------------------------------+
+| *<* | Lists results that are less than the value you specify. |
++--------------------+----------------------------------------------------------------------+
+| *>* | Lists results that are more than the value you specify. |
++--------------------+----------------------------------------------------------------------+
+| *and* | Lists results that match both values you specify. |
++--------------------+----------------------------------------------------------------------+
+| *or* | Lists results that match either of the two values you specify. |
++--------------------+----------------------------------------------------------------------+
+| *>=* | Lists results that are more than or equal to the value you specify. |
++--------------------+----------------------------------------------------------------------+
+| *<=* | Lists results that are less than or equal to the value you specify. |
++--------------------+----------------------------------------------------------------------+
+| *is null* | Lists results for which no value is assigned. |
++--------------------+----------------------------------------------------------------------+
+| *not null* | Lists results for which any value is assigned. |
++--------------------+----------------------------------------------------------------------+
+| *skip* | Use this operator to list matching results from a child node, |
+| | even if its parent node does not meet the specified criteria. |
+| | See the following example for more information. |
++--------------------+----------------------------------------------------------------------+
+
+Example: Skip Criteria Operator
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If you are looking at the following structure and want to determine all of the
+ports that belong to a YY type module:
+
+* Network Element 1
+
+ * Module 1, Type XX
+
+ * Module 1.1, Type YY
+
+ * Port 1
+ * Port 2
+
+ * Module 2, Type YY
+
+ * Port 1
+ * Port 2
+
+If you specify *Module.Type='YY'* in your query criteria, the ports associated
+with module 1.1 will not be returned since its parent module is type XX.
+Instead, enter *Module.Type='YY' or skip Module!='YY'*. This tells XSQL to
+disregard any parent module data that does not meet the type YY criteria and
+collect results for any matching child modules. In this example, you are
+instructing the query to skip module 1 and collect the relevant data from
+module 1.1.
other_features
api
installing_opendaylight
+ release_notes
+ project-specific-guides/index
+ common-features/index
+ security_considerations
+
+.. _install_odl:
+
Installing OpenDaylight
=======================
Install OpenDaylight
--------------------
+Downloading and installing OpenDaylight
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The default distribution can be found on the OpenDaylight software
+download page: http://www.opendaylight.org/software/downloads
+
+The Karaf distribution has no features enabled by default. However, all
+of the features are available to be installed.
+
+.. note:: For compatibility reasons, you cannot enable all the features
+ simultaneously. We try to document known incompatibilities in
+ the `Install the Karaf features`_ section below.
+
+Running the karaf distribution
+""""""""""""""""""""""""""""""
+
+To run the Karaf distribution:
+
+#. Unzip the zip file.
+#. Navigate to the directory.
+#. run ``./bin/karaf``.
+
+For Example::
+
+ $ ls distribution-karaf-0.4.0-Beryllium.zip
+ distribution-karaf-0.4.0-Beryllium.zip
+ $ unzip distribution-karaf-0.4.0-Beryllium.zip
+ Archive: distribution-karaf-0.4.0-Beryllium.zip
+ creating: distribution-karaf-0.4.0-Beryllium/
+ creating: distribution-karaf-0.4.0-Beryllium/configuration/
+ creating: distribution-karaf-0.4.0-Beryllium/data/
+ creating: distribution-karaf-0.4.0-Beryllium/data/tmp/
+ creating: distribution-karaf-0.4.0-Beryllium/deploy/
+ creating: distribution-karaf-0.4.0-Beryllium/etc/
+ creating: distribution-karaf-0.4.0-Beryllium/externalapps/
+ ...
+ inflating: distribution-karaf-0.4.0-Beryllium/bin/start.bat
+ inflating: distribution-karaf-0.4.0-Beryllium/bin/status.bat
+ inflating: distribution-karaf-0.4.0-Beryllium/bin/stop.bat
+ $ cd distribution-karaf-0.4.0-Beryllium
+ $ ./bin/karaf
+
+ ________ ________ .__ .__ .__ __
+ \_____ \ ______ ____ ____ \______ \ _____ ___.__.\| \| \|__\| ____ \| \|___/ \|_
+ / \| \\____ \_/ __ \ / \ \| \| \\__ \< \| \|\| \| \| \|/ ___\\| \| \ __\
+ / \| \ \|_> > ___/\| \| \\| ` \/ __ \\___ \|\| \|_\| / /_/ > Y \ \|
+ \_______ / __/ \___ >___\| /_______ (____ / ____\|\|____/__\___ /\|___\| /__\|
+ \/\|__\| \/ \/ \/ \/\/ /_____/ \/
+
+
+
+* Press ``tab`` for a list of available commands
+* Typing ``[cmd] --help`` will show help for a specific command.
+* Press ``ctrl-d`` or type ``system:shutdown`` or ``logout`` to shutdown OpenDaylight.
+
Install the Karaf features
--------------------------
To install a feature, use the following command, where feature1 is the feature
simultaneously. The table below documents feature installation names and
known incompatibilities.Compatibility values indicate the following:
-* *all* - the feature can be run with other features.
-* *self+all* - the feature can be installed with other features with a value of
- *all*, but may interact badly with other features that have a value of
- *self+all*. Not every combination has been tested.
+* **all** - the feature can be run with other features.
+* **self+all** - the feature can be installed with other features with a value of
+ **all**, but may interact badly with other features that have a value of
+ **self+all**. Not every combination has been tested.
Uninstalling features
^^^^^^^^^^^^^^^^^^^^^
feature:list -i
-Features to implement networking functionality provide release notes you can
-access on the OpenDaylight Wiki: https://wiki.opendaylight.org/view/Project_list
-
-* Authentication, Authorization and Accounting (AAA_)
-* ALTO_
-* BGPCEP_
-* Controller_
-* Control And Provisioning of Wireless Access Points (CAPWAP_)
-* Identification and Driver Management (DIDM_)
-* DLUX_
-* FaaS_
-* Group_Based_Policy_ (GPB)
-* Internet of Things Data Management (IoTDM_)
-* L2_Switch_
-* Link Aggregation Control Protocol (LACP_)
-* LISP_Flow_Mapping_
-* MDSAL_
-* NEMO_
-* NETCONF_
-* NetIDE_
-* NeXt_
-* Network Intent Composition (NIC_)
-* Neutron_Northbound_
-* OF-Config_
-* OpFlex_
-* OpenFlow_Plugin_
-* OpenFlow_Protocol_Library_
-* OVSDB_Netvirt_
-* Packet_Cable_ / PCMM
-* SDN_Interface_Application_
-* Secure Network Bootstrapping Infrastructure (SNBI_)
-* SNMP4SDN_
-* SNMP_Plugin_
-* Secure tag eXchange Protocol (SXP_)
-* Service Function Chaining (SFC_)
-* TCPMD5_
-* Time Series Data Repository (TSDR_)
-* Table Type Patterns (TTP_)
-* Topology_Processing_Framework_
-* Unified Secure Channel (USC_)
-* VPN_Service_
-* Virtual Tenant Network (VTN_)
-* YANG_Tools_
-
-Projects without Release Notes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The following projects participated in Beryllium, but intentionally do not have
-release notes:
-
-* The Documentation Project produced this and the other downloadable
- documentation.
-* The Integration Group hosted the OpenDaylight-wide tests and main release
- distribution.
-* Controller Core Functionality Tutorials provided a single test suite
- (dsbenchmark) that was used as part of integration testing
-* Release Engineering used autorelease to build the Beryllium release artifacts,
- including the main release download.
+Features to implement networking functionality provide release notes, which
+you can find in the :ref:`proj_rel_notes` section.
Beryllium features
------------------
Most components that offer REST APIs will automatically load the RESTCONF API
Support component, but if for whatever reason they seem to be missing, install
the “odl-restconf” feature to activate this support.
-
-
-Install the DLUX interface
---------------------------
-OpenDaylight’s DLUX web interface draws information from topology and host
-databases to display information about the topology of the network, flow
-statistics, and host locations.
-
-To integrate with OpenDaylight you must enable the DLUX Karaf feature. Each
-feature can be enabled or disabled separately. Ensure that you have created a
-topology and enabled the MD-SAL feature in the Karaf distribution before you
-use DLUX for network management. For more information about enabling the Karaf
-features for DLUX, refer to Enable_DLUX_Feature_.
-
-MD-SAL clustering
------------------
-In the Beryllium release and newer, the odl-mdsal-broker installs MD-SAL
-clustering automatically.
-
-.. _Enable_DLUX_Feature: https://wiki.opendaylight.org/view/DLUX:Beryllium_System_Test_Plan#Enabling_The_Feature
-
-
-.. _AAA: https://wiki.opendaylight.org/view/AAA:Beryllium_Release_Notes
-.. _ALTO: https://wiki.opendaylight.org/view/ALTO:Beryllium:Release_Notes
-.. _BGPCEP: https://wiki.opendaylight.org/view/BGP_LS_PCEP:Beryllium_Release_Notes
-.. _CAPWAP: https://wiki.opendaylight.org/view/CAPWAP:Beryllium:Release_Notes
-.. _Controller: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Beryllium:Release_Notes
-.. _DIDM: https://wiki.opendaylight.org/view/DIDM:_Beryllium_Release_Notes
-.. _DLUX: https://wiki.opendaylight.org/view/OpenDaylight_DLUX:Beryllium:Release_Notes
-.. _FaaS: https://wiki.opendaylight.org/view/FaaS:Beryllium_Release_Notes
-.. _Group_Based_Policy: https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Releases/Beryllium:Beryllium_Release_Notes
-.. _IoTDM: https://wiki.opendaylight.org/view/Iotdm:Beryllium_Release_Notes
-.. _L2_Switch: https://wiki.opendaylight.org/view/L2_Switch:Beryllium:Release_Notes
-.. _LACP: https://wiki.opendaylight.org/view/LACP:Beryllium:Release_Notes
-.. _LISP_Flow_Mapping: https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Beryllium_Release_Notes
-.. _MDSAL: https://wiki.opendaylight.org/view/MD-SAL:Beryllium:Release_Notes
-.. _NEMO: https://wiki.opendaylight.org/view/NEMO:Beryllium:Release_Notes
-.. _NETCONF: https://wiki.opendaylight.org/view/OpenDaylight_NETCONF:Beryllium_Release_Notes
-.. _NetIDE: https://wiki.opendaylight.org/view/NetIDE:Release_Notes
-.. _NeXt: https://wiki.opendaylight.org/view/NeXt:Beryllium_Release_Notes
-.. _NIC: https://wiki.opendaylight.org/view/Network_Intent_Composition:Release_Notes
-.. _Neutron_Northbound: https://wiki.opendaylight.org/view/NeutronNorthbound:Beryllium:Release_Notes
-.. _OF-Config: https://wiki.opendaylight.org/view/OF-CONFIG:Beryllium:Release_Notes
-.. _OpFlex: https://wiki.opendaylight.org/view/OpFlex:Beryllium_Release_Notes
-.. _OpenFlow_Plugin: https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Beryllium_Release_Notes
-.. _OpenFlow_Protocol_Library: https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Release_Notes:Beryllium_Release_Notes
-.. _OVSDB_Netvirt: https://wiki.opendaylight.org/view/OpenDaylight_OVSDB:Beryllium_Release_Notes
-.. _Packet_Cable: https://wiki.opendaylight.org/view/PacketCablePCMM:BerylliumReleaseNotes
-.. _SDN_Interface_Application: https://wiki.opendaylight.org/view/ODL-SDNi:Beryllium_Release_Notes
-.. _SNBI: https://wiki.opendaylight.org/view/SNBI_Berrylium_Release_Notes
-.. _SNMP4SDN: https://wiki.opendaylight.org/view/SNMP4SDN:Beryllium_Release_Note
-.. _SNMP_Plugin: https://wiki.opendaylight.org/view/SNMP_Plugin:SNMP_Plugin:Beryllium_Release_Notes
-.. _SXP: https://wiki.opendaylight.org/view/SXP:Beryllium:Release_Notes
-.. _SFC: https://wiki.opendaylight.org/view/Service_Function_Chaining:Beryllium_Release_Notes
-.. _TCPMD5: https://wiki.opendaylight.org/view/TCPMD5:Beryllium_Release_Notes
-.. _TSDR: https://wiki.opendaylight.org/view/TSDR:Beryllium:Release_Notes
-.. _TTP: https://wiki.opendaylight.org/view/Table_Type_Patterns/Beryllium/Release_Notes
-.. _Topology_Processing_Framework: https://wiki.opendaylight.org/view/Topology_Processing_Framework:BERYLLIUM_Release_Notes
-.. _USC: https://wiki.opendaylight.org/view/USC:Beryllium:Release_Notes
-.. _VPN_Service: https://wiki.opendaylight.org/view/Vpnservice:Beryllium_Release_Notes
-.. _VTN: https://wiki.opendaylight.org/view/VTN:Beryllium:Release_Notes
-.. _YANG_Tools: https://wiki.opendaylight.org/view/YANG_Tools:Beryllium:Release_Notes
TSDR through REST APIs
* NBI integration with Grafana - Allows visualization of data collected in TSDR
using Grafana
+* Data Aggregation Service - Periodically aggregates raw data into larger time granularities
* Data Purging Service - Periodically purges data from TSDR
* Data Collection Framework - Data Collection framework to allow plugging in of
various types of collectors
introduced in Beryllium
* Cassandra data store - Cassandra implementation of TSDR SPIs
* NetFlow data collector - Collect NetFlow data from network elements
+* NetFlowV9 - version 9 Netflow collector
* SNMP Data Collector - Integrates with SNMP plugin to bring SNMP data into TSDR
+* sFlowCollector - Collects sFlow data from network elements
* Syslog data collector - Collects syslog data from network elements
TSDR has multiple features to enable the functionality above. To begin,
* odl-tsdr-openflow-statistics-collector
* odl-tsdr-netflow-statistics-collector
* odl-tsdr-controller-metrics-collector
+* odl-tsdr-sflow-statistics-collector
* odl-tsdr-snmp-data-collector
* odl-tsdr-syslog-collector
--- /dev/null
+Project-Specific Installation Guides
+====================================
+
+.. toctree::
+ :maxdepth: 1
+
+ opflex
+ ovsdb-openstack
+ tsdr
+ vtn
+ yangide
+
--- /dev/null
+OpFlex agent-ovs Install Guide
+==============================
+
+Required Packages
+-----------------
+
+You'll need to install the following packages and their dependencies:
+
+* libuv
+* openvswitch-gbp
+* openvswitch-gbp-lib
+* openvswitch-gbp-kmod
+* libopflex
+* libmodelgbp
+* agent-ovs
+
+Packages are available for Red Hat Enterprise Linux 7 and Ubuntu 14.04
+LTS. Some of the examples below are specific to RHEL7 but you can run
+the equivalent commands for upstart instead of systemd.
+
+Note that many of these steps may be performed automatically if you're
+deploying this along with a larger orchestration system.
+
+Host Networking Configuration
+-----------------------------
+
+You'll need to set up your VM host uplink interface. You should
+ensure that the MTU of the underlying network is sufficient to handle
+tunneled traffic. We will use an example of setting up *eth0* as your
+uplink interface with a vlan of 4093 used for the networking control
+infrastructure and tunnel data plane.
+
+We just need to set the MTU and disable IPv4 and IPv6
+autoconfiguration. The MTU needs to be large enough to allow both the
+VXLAN header and VLAN tags to pass through without fragmenting for
+best performance. We'll use 1600 bytes which should be sufficient
+assuming you are using a default 1500 byte MTU on your virtual machine
+traffic. If you already have any NetworkManager connections configured
+for your uplink interface find the connection name and proceed to the
+next step. Otherwise, create a connection with (be sure to update the
+variable UPLINK_IFACE as needed)::
+
+ UPLINK_IFACE=eth0
+ nmcli c add type ethernet ifname $UPLINK_IFACE
+
+Now, configure your interface as follows::
+
+ CONNECTION_NAME="ethernet-$UPLINK_IFACE"
+ nmcli connection mod "$CONNECTION_NAME" connection.autoconnect yes \
+ ipv4.method link-local \
+ ipv6.method ignore \
+ 802-3-ethernet.mtu 9000 \
+ ipv4.routes '224.0.0.0/4 0.0.0.0 2000'
+
+Then bring up the interface with::
+
+ nmcli connection up "$CONNECTION_NAME"
+
+Next, create the infrastructure interface using the infrastructure
+VLAN (4093 by default). We'll need to create a vlan subinterface of
+your uplink interface, the configure DHCP on that interface. Run the
+following commands. Be sure to replace the variable values if needed. If
+you're not using NIC teaming, replace the variable team0 below::
+
+ UPLINK_IFACE=team0
+ INFRA_VLAN=4093
+ nmcli connection add type vlan ifname $UPLINK_IFACE.$INFRA_VLAN dev $UPLINK_IFACE id $INFRA_VLAN
+ nmcli connection mod vlan-$UPLINK_IFACE.$INFRA_VLAN \
+ ethernet.mtu 1600 ipv4.routes '224.0.0.0/4 0.0.0.0 1000'
+ sed "s/CLIENT_ID/01:$(ip link show $UPLINK_IFACE | awk '/ether/ {print $2}')/" \
+ > /etc/dhcp/dhclient-$UPLINK_IFACE.$INFRA_VLAN.conf <<EOF
+ send dhcp-client-identifier CLIENT_ID;
+ request subnet-mask, domain-name, domain-name-servers, host-name;
+ EOF
+
+Now bring up the new interface with::
+
+ nmcli connection up vlan-$UPLINK_IFACE.$INFRA_VLAN
+
+If you were successful, you should be able to see an IP address when you run::
+
+ ip addr show dev $UPLINK_IFACE.$INFRA_VLAN
+
+OVS Bridge Configuration
+------------------------
+
+We'll need to configure an OVS bridge which will handle the traffic
+for any virtual machines or containers that are hosted on the VM
+host. First, enable the openvswitch service and start it::
+
+ # systemctl enable openvswitch
+ ln -s '/usr/lib/systemd/system/openvswitch.service' '/etc/systemd/system/multi-user.target.wants/openvswitch.service'
+ # systemctl start openvswitch
+ # systemctl status openvswitch
+ openvswitch.service - Open vSwitch
+ Loaded: loaded (/usr/lib/systemd/system/openvswitch.service; enabled)
+ Active: active (exited) since Fri 2014-12-12 17:20:13 PST; 3s ago
+ Process: 3053 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
+ Main PID: 3053 (code=exited, status=0/SUCCESS)
+ Dec 12 17:20:13 ovs-server.cisco.com systemd[1]: Started Open vSwitch.
+
+Next, we can create an OVS bridge (you may wish to use a different
+bridge name)::
+
+ # ovs-vsctl add-br br0
+ # ovs-vsctl show
+ 34aa83d7-b918-4e49-bcec-1b521acd1962
+ Bridge "br0"
+ Port "br0"
+ Interface "br0"
+ type: internal
+ ovs_version: "2.3.90"
+
+Next, we configure a tunnel interface on our new bridge as follows::
+
+ # ovs-vsctl add-port br0 br0_vxlan0 -- \
+ set Interface br0_vxlan0 type=vxlan \
+ options:remote_ip=flow options:key=flow options:dst_port=8472
+ # ovs-vsctl show
+ 34aa83d7-b918-4e49-bcec-1b521acd1962
+ Bridge "br0"
+ Port "br0_vxlan0"
+ Interface "br0_vxlan0"
+ type: vxlan
+ options: {dst_port="8472", key=flow, remote_ip=flow}
+ Port "br0"
+ Interface "br0"
+ type: internal
+ ovs_version: "2.3.90"
+
+Open vSwitch is now configured and ready.
+
+Agent Configuration
+-------------------
+
+Before enabling the agent, we'll need to edit its configuration file,
+which is located at "/etc/opflex-agent-ovs/opflex-agent-ovs.conf".
+
+First, we'll configure the Opflex protocol parameters. If you're using
+an ACI fabric, you'll need the OpFlex domain from the ACI
+configuration, which is the name of the VMM domain you mapped to the
+interface for this hypervisor. Set the "domain" field to this
+value. Next, set the "name" field to a hostname or other unique
+identifier for the VM host. Finally, set the "peers" list to contain
+the fixed static anycast peer address of 10.0.0.30 and port 8009. Here
+is an example of a completed section (bold text shows areas you'll
+need to modify)::
+
+ "opflex": {
+ // The globally unique policy domain for this agent.
+ "domain": "[CHANGE ME]",
+
+ // The unique name in the policy domain for this agent.
+ "name": "[CHANGE ME]",
+
+ // a list of peers to connect to, by hostname and port. One
+ // peer, or an anycast pseudo-peer, is sufficient to bootstrap
+ // the connection without needing an exhaustive list of all
+ // peers.
+ "peers": [
+ {"hostname": "10.0.0.30", "port": 8009}
+ ],
+
+ "ssl": {
+ // SSL mode. Possible values:
+ // disabled: communicate without encryption
+ // encrypted: encrypt but do not verify peers
+ // secure: encrypt and verify peer certificates
+ "mode": "encrypted",
+
+ // The path to a directory containing trusted certificate
+ // authority public certificates, or a file containing a
+ // specific CA certificate.
+ "ca-store": "/etc/ssl/certs/"
+ }
+ },
+
+Next, configure the appropriate policy renderer for the ACI
+fabric. You'll want to use a stitched-mode renderer. You'll need to
+configure the bridge name and the uplink interface name. The remote
+anycast IP address will need to be obtained from the ACI configuration
+console, but unless the configuration is unusual, it will be
+10.0.0.32::
+
+ // Renderers enforce policy obtained via OpFlex.
+ "renderers": {
+ // Stitched-mode renderer for interoperating with a
+ // hardware fabric such as ACI
+ "stitched-mode": {
+ "ovs-bridge-name": "br0",
+
+ // Set encapsulation type. Must set either vxlan or vlan.
+ "encap": {
+ // Encapsulate traffic with VXLAN.
+ "vxlan" : {
+ // The name of the tunnel interface in OVS
+ "encap-iface": "br0_vxlan0",
+
+ // The name of the interface whose IP should be used
+ // as the source IP in encapsulated traffic.
+ "uplink-iface": "eth0.4093",
+
+ // The vlan tag, if any, used on the uplink interface.
+ // Set to zero or omit if the uplink is untagged.
+ "uplink-vlan": 4093,
+
+ // The IP address used for the destination IP in
+ // the encapsulated traffic. This should be an
+ // anycast IP address understood by the upstream
+ // stitched-mode fabric.
+ "remote-ip": "10.0.0.32"
+ }
+ },
+ // Configure forwarding policy
+ "forwarding": {
+ // Configure the virtual distributed router
+ "virtual-router": {
+ // Enable virtual distributed router. Set to true
+ // to enable or false to disable. Default true.
+ "enabled": true,
+
+ // Override MAC address for virtual router.
+ // Default is "00:22:bd:f8:19:ff"
+ "mac": "00:22:bd:f8:19:ff",
+
+ // Configure IPv6-related settings for the virtual
+ // router
+ "ipv6" : {
+ // Send router advertisement messages in
+ // response to router solicitation requests as
+ // well as unsolicited advertisements.
+ "router-advertisement": true
+ }
+ },
+
+ // Configure virtual distributed DHCP server
+ "virtual-dhcp": {
+ // Enable virtual distributed DHCP server. Set to
+ // true to enable or false to disable. Default
+ // true.
+ "enabled": true,
+
+ // Override MAC address for virtual dhcp server.
+ // Default is "00:22:bd:f8:19:ff"
+ "mac": "00:22:bd:f8:19:ff"
+ }
+ },
+
+ // Location to store cached IDs for managing flow state
+ "flowid-cache-dir": "DEFAULT_FLOWID_CACHE_DIR"
+ }
+ }
+
+Finally, enable the agent service::
+
+ # systemctl enable agent-ovs
+ ln -s '/usr/lib/systemd/system/agent-ovs.service' '/etc/systemd/system/multi-user.target.wants/agent-ovs.service'
+ # systemctl start agent-ovs
+ # systemctl status agent-ovs
+ agent-ovs.service - Opflex OVS Agent
+ Loaded: loaded (/usr/lib/systemd/system/agent-ovs.service; enabled)
+ Active: active (running) since Mon 2014-12-15 10:03:42 PST; 5min ago
+ Main PID: 6062 (agent_ovs)
+ CGroup: /system.slice/agent-ovs.service
+ └─6062 /usr/bin/agent_ovs
+
+The agent is now running and ready to enforce policy. You can add
+endpoints to the local VM hosts using the OpFlex Group-based policy
+plugin from OpenStack, or manually.
--- /dev/null
+OVSDB OpenStack Installation Guide
+==================================
+
+Overview
+^^^^^^^^
+
+This guide is geared towards installing OpenDaylight to use the OVSDB project to provide Neutron support for OpenStack.
+
+Open vSwitch (OVS) is generally accepted as the unofficial standard for Virtual Switching in the Open hypervisor based solutions.
+For information on OVS, see `Open vSwitch <http://openvswitch.org/>`_.
+
+With OpenStack within the SDN context, controllers and applications interact using two channels: OpenFlow and OVSDB. OpenFlow addresses the forwarding-side of the OVS functionality. OVSDB, on the other hand, addresses the management-plane.
+A simple and concise overview of Open Virtual Switch Database (OVSDB) is available at: http://networkstatic.net/getting-started-ovsdb/
+
+Preparing for Installation
+--------------------------
+
+Follow the instructions in :ref:`install_odl`.
+
+Installing OVSDB OpenStack
+--------------------------
+
+Install the required features with the following command::
+
+ feature:install odl-ovsdb-openstack
+
+Sample output from the Karaf console
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: shell
+
+ opendaylight-user@root>feature:list -i | grep ovsdb
+ odl-ovsdb-southbound-api | 1.1.0-SNAPSHOT | x | odl-ovsdb-southbound-1.1.0-SNAPSHOT
+ OpenDaylight :: southbound :: api
+ odl-ovsdb-southbound-impl | 1.1.0-SNAPSHOT | x | odl-ovsdb-southbound-1.1.0-SNAPSHOT
+ OpenDaylight :: southbound :: impl
+ odl-ovsdb-southbound-impl-rest | 1.1.0-SNAPSHOT | x | odl-ovsdb-southbound-1.1.0-SNAPSHOT
+ OpenDaylight :: southbound :: impl :: REST
+ odl-ovsdb-southbound-impl-ui | 1.1.0-SNAPSHOT | x | odl-ovsdb-southbound-1.1.0-SNAPSHOT
+ OpenDaylight :: southbound :: impl :: UI
+ odl-ovsdb-openstack | 1.1.0-SNAPSHOT | x | ovsdb-1.1.0-SNAPSHOT
+ OpenDaylight :: OVSDB :: OpenStack Network Virtual
+
+Verifying your Installation
+---------------------------
+
+To verify that the installation was successful, use the following command in karaf and check that there are no errors
+logs relating to odl-ovsdb-openstack::
+
+ log:display
+
+Troubleshooting
+^^^^^^^^^^^^^^^
+
+There is no easy way to troubleshoot an installation of odl-ovsdb-openstack. Perhaps a combination of
+log:display | grep -i ovsdb in karaf, Open vSwitch commands (ovs-vsctl) and OpenStack logs will be useful but will not
+explain everything.
+
+Uninstalling OVSDB OpenStack
+----------------------------
+
+#. Shutdown the karaf instance::
+
+ system:shutdown
+
+#. Remove what is in the ``/data`` folder of the OpenDaylight distribution.
--- /dev/null
+TSDR Installation Guide
+=======================
+
+This document is for the user to install the artifacts that are needed
+for using Time Series Data Repository (TSDR) functionality in the ODL
+Controller by enabling either an HSQLDB, HBase, or Cassandra Data Store.
+
+
+Overview
+--------
+
+The Time Series Data Repository (TSDR) project in OpenDaylight (ODL) creates a framework for collecting, storing, querying, and maintaining time series data in the OpenDaylight SDN controller. Please refer to the User Guide for the detailed description of the functionality of the project and how to use the corresponding features provided in TSDR.
+
+Pre Requisites for Installing TSDR
+----------------------------------
+
+The software requirements for TSDR HBase Data Store are as follows:
+
+* In the case when the user chooses HBase or Cassandra data store, besides the software that ODL requires, we also require HBase and Cassandra database running in single node deployment scenario.
+
+No additional software is required for the HSQLDB Data Stores.
+
+Preparing for Installation
+--------------------------
+
+* When using HBase data store, download HBase from the following website:
+
+ http://archive.apache.org/dist/hbase/hbase-0.94.15/
+
+* When using Cassandra data store, download Cassandra from the following website:
+
+ http://www.eu.apache.org/dist/cassandra/2.1.10/
+
+* No additional steps are required to install the TSDR HSQL Data Store.
+
+Installing TSDR Data Stores
+---------------------------
+
+Installing HSQLDB Data Store
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Once OpenDaylight distribution is up, from karaf console install the HSQLDB data store using the following command::
+
+ feature:install odl-tsdr-hsqldb-all
+
+This will install hsqldb related dependency features (and can take sometime) as well as openflow statistics collector before returning control to the console.
+
+
+Installing HBase Data Store
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Installing TSDR HBase Data Store contains two steps:
+
+#. Installing HBase server, and
+#. Installing TSDR HBase Data Store features from ODL Karaf console.
+
+In Beryllium, we only support HBase single node running together on the same machine as OpenDaylight. Therefore, follow the steps to download and install HBase server onto the same machine as where OpenDaylight is running:
+
+#. Create a folder in Linux operating system for the HBase server. For example, create an hbase directory under ``/usr/lib``::
+
+ mkdir /usr/lib/hbase
+
+#. Unzip the downloaded HBase server tar file.
+
+ Run the following command to unzip the installation package::
+
+ tar xvf <hbase-installer-name> /usr/lib/hbase
+
+#. Make proper changes in hbase-site.xml
+
+ #. Under <hbase-install-directory>/conf/, there is a hbase-site.xml. Although it is not recommended, an experienced user with HBase can modify the data directory for hbase server to store the data.
+
+ #. Modify the value of the property with name "hbase.rootdir" in the file to reflect the desired file directory for storing hbase data.
+
+ The following is an example of the file::
+
+ <configuration>
+ <property>
+ <name>hbase.rootdir</name>
+ <value>file:///usr/lib/hbase/data</value>
+ </property>
+ <property>
+ <name>hbase.zookeeper.property.dataDir</name>
+ <value>/usr/lib/hbase/zookeeper</value>
+ </property>
+ </configuration>
+
+#. start hbase server::
+
+ cd <hbase-installation-directory>
+ ./start-hbase.sh
+
+#. start hbase shell::
+
+ cd <hbase-insatllation-directory>
+ ./hbase shell
+
+#. start Karaf console
+
+#. install hbase data store feature from Karaf console::
+
+ feature:install odl-tsdr-hbase
+
+Installing Cassandra Data Store
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Installing TSDR Cassandra Data Store contains two steps:
+
+#. Installing Cassandra server, and
+#. Installing TSDR Cassandra Data Store features from ODL Karaf console.
+
+In Beryllium, we only support Cassadra single node running together on the same machine as OpenDaylight. Therefore, follow these steps to download and install Cassandra server onto the same machine as where OpenDaylight is running:
+
+#. Install Cassandra (latest stable version) by downloading the zip file and untar the tar ball to cassandra/ directory on the testing machine::
+
+ mkdir cassandra
+ wget http://www.eu.apache.org/dist/cassandra/2.1.10/apache-cassandra-2.1.10-bin.tar.gz[2.1.10 is current stable version, it can vary]
+ mv apache-cassandra-2.1.10-bin.tar.gz cassandra/
+ cd cassandra
+ tar -xvzf apache-cassandra-2.1.10-bin.tar.gz
+
+#. Start Cassandra from cassandra directory by running::
+
+ ./apache-cassandra-2.1.10/bin/cassandra
+
+#. Start cassandra shell by running::
+
+ ./apache-cassandra-2.1.10/bin/cqlsh
+
+#. Start Karaf according to the instructions above.
+
+#. Install Cassandra data store feature from Karaf console::
+
+ feature:install odl-tsdr-cassandra
+
+Verifying your Installation
+---------------------------
+
+After the TSDR data store is installed, no matter whether it is HBase data store, Cassandra data store, or HSQLDB data store, the user can verify the installation with the following steps.
+
+#. Verify if the following two tsdr commands are available from Karaf console::
+
+ tsdr:list
+ tsdr:purgeAll
+
+#. Verify if openflow statisitcs data can be received successfully:
+
+ #. Run "feature:install odl-tsdr-openflow-statistics-collector" from Karaf.
+
+ #. Run mininet to connect to ODL controller. For example, use the following command to start a three node topology::
+
+ mn --topo single,3 --controller 'remote,ip=172.17.252.210,port=6653' --switch ovsk,protocols=OpenFlow13
+
+ #. From Karaf console, the user should be able to retrieve the statistics data of OpenFlow statistics data from the console::
+
+ tsdr:list FLOWSTATS
+
+Troubleshooting
+^^^^^^^^^^^^^^^
+
+Check the ``../data/log/karaf.log`` for any exception related to TSDR features.
+
+Post Installation Configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Post Installation Configuration for HSQLDB Data Store
+"""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+The feature installation takes care of automated configuration of the datasource by installing a file in <install folder>/etc named org.ops4j.datasource-metric.cfg. This contains the default location of <install folder>/tsdr where the HSQLDB datastore files are stored. If you want to change the default location of the datastore files to some other location update the last portion of the url property in the org.ops4j.datasource-metric.cfg and then restart the Karaf container.
+
+Post Installation Configuration for HBase Data Store
+""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+Please refer to HBase Data Store User Guide.
+
+Post Installation Configuration for Cassandra Data Store
+""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+There is no post configuration for TSDR Cassandra data store.
+
+Upgrading From a Previous Release
+---------------------------------
+
+The HBase data store was supported in the previous release as well as in this release. However, we do not support data store upgrade for HBase data store.
+The user needs to reinstall TSDR and start to collect data in TSDR HBase datastore after the installation.
+
+HSQLDB and Cassandra are new data stores introduced in this release. Therefore, upgrading from previous release does not apply in these two data store scenarios.
+
+Uninstalling TSDR Data Stores
+-----------------------------
+
+To uninstall TSDR HSQLDB data store
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To uninstall the TSDR functionality with the default store, you need to do the following from karaf console::
+
+ feature:uninstall odl-tsdr-hsqldb-all
+ feature:uninstall odl-tsdr-core
+ feature:uninstall odl-tsdr-hsqldb
+ feature:uninstall odl-tsdr-openflow-statistics-collector
+
+It is recommended to restart the Karaf container after the uninstallation of the TSDR functionality with the default store.
+
+To uninstall TSDR HBase Data Store
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To uninstall the TSDR functionality with the HBase data store,
+
+* Uninstall HBase data store related features from karaf console::
+
+ feature:uninstall odl-tsdr-hbase
+ feature:uninstall odl-tsdr-core
+
+* stop hbase server::
+
+ cd <hbase-installation-directory>
+ ./stop-hbase.sh
+
+* remove the file directory that contains the HBase server installation::
+
+ rm -r <hbase-installation-directory>
+
+It is recommended to restart the Karaf container after the uninstallation of the TSDR data store.
+
+To uninstall TSDR Cassandra Data Store
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To uninstall the TSDR functionality with the Cassandra store,
+
+* uninstall cassandra data store related features following from karaf console::
+
+ feature:uninstall odl-tsdr-cassandra
+ feature:uninstall odl-tsdr-core
+
+* stop cassandra database::
+
+ ps auwx | grep cassandra
+ sudo kill pid
+
+* remove the cassandra installation files::
+
+ rm <cassandra-installation-directory>
+
+It is recommended to restart the Karaf container after uninstallation of the TSDR data store.
-== VTN Installation Guide
+VTN Installation Guide
+======================
-=== Overview
+Overview
+--------
OpenDaylight Virtual Tenant Network (VTN) is an application that provides multi-tenant virtual network on an SDN controller.
It is implemented as two major components
-* <<_vtn_manager,VTN Manager>>
-* <<_vtn_coordinator,VTN Coordinator>>
+* :ref:`vtn_manager`
+* :ref:`vtn_coordinator`
-==== VTN Manager
-An OpenDaylight Plugin that interacts with other modules to implement the components of the VTN model. It also provides a REST interface to configure VTN components in OpenDaylight. VTN Manager is implemented as one plugin to the OpenDaylight. This provides a REST interface to create/update/delete VTN components. The user command in VTN Coordinator is translated as REST API to VTN Manager by the OpenDaylight Driver component. In addition to the above mentioned role, it also provides an implementation to the OpenStack L2 Network Functions API.
+.. _vtn_manager:
-==== VTN Coordinator
+VTN Manager
+^^^^^^^^^^^
-The VTN Coordinator is an external application that provides a REST interface for an user to use OpenDaylight VTN Virtualization. It interacts with VTN Manager plugin to implement the user configuration. It is also capable of multiple OpenDaylight orchestration. It realizes VTN provisioning in OpenDaylight instances. In the OpenDaylight architecture VTN Coordinator is part of the network application, orchestration and services layer. VTN Coordinator will use the REST interface exposed by the VTN Manger to realize the virtual network using OpenDaylight. It uses OpenDaylight APIs (REST) to construct the virtual network in OpenDaylight instances. It provides REST APIs for northbound VTN applications and supports virtual networks spanning across multiple OpenDaylight by coordinating across OpenDaylight.
+An OpenDaylight Plugin that interacts with other modules to implement the components of the VTN model. It also provides a REST interface to configure VTN components in OpenDaylight. VTN Manager is implemented as one plugin to the OpenDaylight. This provides a REST interface to create/update/delete VTN components. The user command in VTN Coordinator is translated as REST API to VTN Manager by the OpenDaylight Driver component. In addition to the above mentioned role, it also provides an implementation to the OpenStack L2 Network Functions API.
+
+.. _vtn_coordinator:
-=== Preparing for Installation
+VTN Coordinator
+^^^^^^^^^^^^^^^
-==== VTN Manager
+The VTN Coordinator is an external application that provides a REST interface for an user to use OpenDaylight VTN Virtualization. It interacts with VTN Manager plugin to implement the user configuration. It is also capable of multiple OpenDaylight orchestration. It realizes VTN provisioning in OpenDaylight instances. In the OpenDaylight architecture VTN Coordinator is part of the network application, orchestration and services layer. VTN Coordinator will use the REST interface exposed by the VTN Manger to realize the virtual network using OpenDaylight. It uses OpenDaylight APIs (REST) to construct the virtual network in OpenDaylight instances. It provides REST APIs for northbound VTN applications and supports virtual networks spanning across multiple OpenDaylight by coordinating across OpenDaylight.
-===== Running the Karaf distribution
+Preparing for Installation
+--------------------------
-Follow the instructions in <<_getting_and_installing_opendaylight,Getting and Installing OpenDaylight>>.
+VTN Manager
+^^^^^^^^^^^
-==== VTN Coordinator
+Follow the instructions in :ref:`install_odl`.
-* Arrange a physical/virtual server with any one of the supported 64-bit OS environment.
-** RHEL 7
-** CentOS 7
-** Fedora 20 / 21 / 22
+VTN Coordinator
+^^^^^^^^^^^^^^^
-* Install these packages
+#. Arrange a physical/virtual server with any one of the supported 64-bit OS environment.
- yum install perl-Digest-SHA uuid libxslt libcurl unixODBC json-c bzip2
+ * RHEL 7
+ * CentOS 7
+ * Fedora 20 / 21 / 22
- rpm -ivh http://yum.postgresql.org/9.3/redhat/rhel-6-x86_64/pgdg-redhat93-9.3-1.noarch.rpm
+#. Install these packages::
- yum install postgresql93-libs postgresql93 postgresql93-server postgresql93-contrib postgresql93-odbc
+ yum install perl-Digest-SHA uuid libxslt libcurl unixODBC json-c bzip2
+ rpm -ivh http://yum.postgresql.org/9.3/redhat/rhel-6-x86_64/pgdg-redhat93-9.3-1.noarch.rpm
+ yum install postgresql93-libs postgresql93 postgresql93-server postgresql93-contrib postgresql93-odbc
-=== Installing VTN
+Installing VTN
+--------------
-==== VTN Manager
+VTN Manager
+^^^^^^^^^^^
-Install Feature
+Install Feature::
- feature:install odl-vtn-manager-neutron odl-vtn-manager-rest
+ feature:install odl-vtn-manager-neutron odl-vtn-manager-rest
-NOTE: The above command will install all features of VTN Manager.
- You can install only REST or Neutron also.
+.. note:: The above command will install all features of VTN Manager.
+ You can install only REST or Neutron also.
-==== VTN Coordinator
+VTN Coordinator
+^^^^^^^^^^^^^^^
-* Enter into the externalapps directory in the top directory of Beryllium
+* Enter into the externalapps directory in the top directory of Beryllium::
- cd distribution-karaf-0.4.0-Beryllium/externalapps
+ cd distribution-karaf-0.4.0-Beryllium/externalapps
-* Run the below command to extract VTN Coordinator from the tar.bz2 file in the externalapps directory.
+* Run the below command to extract VTN Coordinator from the tar.bz2 file in the externalapps directory::
- tar –C/ -jxvf distribution.vtn-coordinator-6.2.0-Beryllium-bin.tar.bz2
+ tar –C/ -jxvf distribution.vtn-coordinator-6.2.0-Beryllium-bin.tar.bz2
This will install VTN Coordinator to /usr/local/vtn directory.
The name of the tar.bz2 file name varies depending on the version. Please give the same tar.bz2 file name which is there in your directory.
-* Configuring database for VTN Coordinator
+* Configuring database for VTN Coordinator::
- /usr/local/vtn/sbin/db_setup
+ /usr/local/vtn/sbin/db_setup
-* To start the Coordinator
+* To start the Coordinator::
- /usr/local/vtn/bin/vtn_start
+ /usr/local/vtn/bin/vtn_start
Using VTN REST API:
-Get the version of VTN REST API using the below command, and make sure the setup is working.
+Get the version of VTN REST API using the below command, and make sure the setup is working::
+
+ curl --user admin:adminpass -H 'content-type: application/json' -X GET http://<VTN_COORDINATOR_IP_ADDRESS>:8083/vtn-webapi/api_version.json
+
+The response should be like this, but version might differ::
+
+ {"api_version":{"version":"V1.2"}}
- curl --user admin:adminpass -H 'content-type: application/json' -X GET http://<VTN_COORDINATOR_IP_ADDRESS>:8083/vtn-webapi/api_version.json
+Verifying your Installation
+---------------------------
-The response should be like this, but version might differ:
+VTN Manager
+^^^^^^^^^^^
- {"api_version":{"version":"V1.2"}}
+* In the karaf prompt, type the below command to ensure that vtn packages are installed::
-=== Verifying your Installation
+ feature:list | grep vtn
-==== VTN Manager
+* Run any VTN Manager REST API::
-* In the karaf prompt, type the below command to ensure that vtn packages are installed.
+ curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X GET http://localhost:8181/restconf/operational/vtn:vtns
- feature:list | grep vtn
+VTN Coordinator
+^^^^^^^^^^^^^^^
-* Run any VTN Manager REST API
+.. code-block:: shell
- curl --user "admin":"admin" -H "Accept: application/json" -H "Content-type: application/json" -X GET http://localhost:8181/restconf/operational/vtn:vtns
+ ps –ef | grep unc will list all the vtn apps
+ Run any REST API for VTN Coordinator version
-==== VTN Coordinator
+Uninstalling VTN
+----------------
-* ps –ef | grep unc will list all the vtn apps
-* Run any REST API for VTN Coordinator version
+VTN Manager
+^^^^^^^^^^^
-=== Uninstalling VTN
+.. code-block:: shell
-==== VTN Manager
+ feature:uninstall odl-vtnmanager-all
- Feature:uninstall odl-vtnmanager-all
+VTN Coordinator
+^^^^^^^^^^^^^^^
-==== VTN Coordinator
+#. Stop VTN::
- /usr/local/vtn/bin/vtn_stop
+ /usr/local/vtn/bin/vtn_stop
- Remove the usr/local/vtn folder
+#. Remove the ``usr/local/vtn`` folder
--- /dev/null
+YangIDE Installation Guide
+==========================
+
+Overview
+--------
+
+The YangIDE project provides an Eclipse plugin for viewing and editing
+Yang model files. When you create a "Yang Project" using the plugin,
+it creates a small Maven project with a POM file (pom.xml) that
+references the appropriate OpenDaylight dependencies, along with a
+sample Yang model file (acme-system.yang).
+
+Pre Requisites for Installing YangIDE
+-------------------------------------
+
+* YangIDE has the same hardware requirements as the Eclipse IDE, which
+ is about the same as the hardware requirements for Java 7.
+* At least Java 7 is required to run Eclipse (also an obvious
+ requirement), but Java 8 will be required if you're building an
+ application using OpenDaylight, and Java 8 is recommended anyway.
+
+Preparing for Installation
+--------------------------
+
+As soon as at least Java 7 (Java 8 preferred) and Eclipse are
+installed, and Eclipse is running, you can install YangIDE.
+
+You can find the Oracle Java installer at
+http://www.oracle.com/technetwork/java/javase/downloads/index.html .
+
+The Eclipse installer can be found at
+http://www.eclipse.org/downloads/ . You should select the "Eclipse
+IDE for Java Developers", and make sure you select the installer for
+the correct platform (for instance, 32-bit or 64-bit).
+
+
+Installing YangIDE
+------------------
+
+The YangIDE plugin can be installed by using the public update site URL
+provided, which is http://abc.def .
+
+While in Eclipse, select "Help" from the menu bar and select "Install
+New Software ...". On the resulting "Install" dialog, click the
+"Add..." button. In that dialog, enter the update site URL as
+specified above and give it a name of "YangIDE". Select the provided
+plugin and approve the license.
+
+Eclipse will prompt you to restart Eclipse. Do that.
+
+Installation is complete at this point.
+
+Verifying your Installation
+---------------------------
+
+This is not really a "usage guide", but following these steps will
+verify that the plugin was properly installed.
+
+When installation is complete, you can select "File" from the menu
+bar, then "New", then "Other" (you may have a keyboard shortcut for
+"Ctrl+n" for this).
+
+In the "New" dialog, you can enter "yang" in the field under the
+"Wizards" label, which starts out with the content of "type filter
+text". That will limit the list to the "YANG" folder and the two
+choices of "YANG File" and "YANG Project". Select the "YANG Project"
+option and click "Next".
+
+On the "New Yang Project" dialog, you may see a wizard page titled
+"Specify YANG Code Generators Parameters". Don't change anything on
+that page and click "Next".
+
+On the next wizard page, with the title "Select project name and
+location", check the "Create a simple project" checkbox and click
+"Next".
+
+On that dialog, enter anything you want in the "Group Id" field.
+Enter a project name (again, whatever you want for now) in the
+"Artifact Id" field and click "Finish". No other fields on the page
+need to be changed.
+
+The dialog will now go away and Eclipse will create the project, which
+you should see in either the "Package Explorer" or "Project Explorer"
+view, on the left side.
+
+Click the arrow just left of the project name to expand the contents
+of the project.
+
+In that resulting list, there are only two entries that you will ever
+care about. One is "src/main/yang", which is where you'll store the
+Yang model files, and the "pom.xml" file, which is where you'll enter
+dependencies for Yang model files to import. If you won't be
+importing any Yang model files, or you'll only be importing other Yang
+model files in your own project, then you'll never have to do anything
+with the "pom.xml" file.
+
+Click the arrow to the left of the "src/main/yang" entry to expand that.
+
+You should see a "acme-system.yang" file, which the plugin created by
+default. Double-click on that entry to open the file in the editor.
+
+Troubleshooting
+^^^^^^^^^^^^^^^
+
+If Eclipse fails to start up initially, then there is something wrong
+with either the Java installation or the Eclipse installation.
+
+You can determine whether Java is installed correctly by opening a
+shell or command window and entering "java -version" and verifying
+whether the output corresponds to the version of Java that you
+installed.
+
+If the Java installation seems fine, but Eclipse still fails to start
+up, you can ask questions on the #eclipse IRC channel, or post
+questions on the "Newcomers" forum at http://www.eclipse.org/forums/ .
+
+If Java and Eclipse seem to be fine, but the YangIDE is having
+problems, ask questions on the "yangide-dev" mailing list.
+
+Post Installation Configuration
+-------------------------------
+
+No post-installation steps are required.
+
+Upgrading From a Previous Release
+---------------------------------
+
+If you already had the "Yang IDE" plugin from "Xored", you'll need to
+uninstall that plugin before you install this one.
+
+Uninstalling YangIDE
+--------------------
+
+Uninstalling the YangIDE plugin is the same as uninstalling any other Eclipse plugin.
+
+Click on the "Help" menu item and select "Installation Details". That
+list will have all the plugins you have installed (or that came with
+the distribution). To uninstall YangIDE, you'll need to select four
+entries from that list:
+
+* "m2e connector for YANG"
+* "m2e connector for YANG Developer Resources"
+* "YANG IDE"
+* "YANG IDE Developer Resources"
+
+Use the Control key to select multiple entries in this list. When all
+four entries are selected, click the "Uninstall" button. The next
+dialog shows what you selected and asks you to confirm with the
+"Finish" button.
+
+It will then uninstall the plugin and prompt you to restart Eclipse.
+When Eclipse restarts, the uninstall process is complete.
--- /dev/null
+Release Notes
+=============
+
+Target Environment
+------------------
+
+For Execution
+^^^^^^^^^^^^^
+
+The OpenDaylight Karaf container, OSGi bundles, and Java class files
+are portable and should run on any Java 7- or Java 8-compliant JVM to
+run. Certain projects and certain features of some projects may have
+additional requirements. Those are noted in the project-specific
+release notes.
+
+Projects and features which have known additional requirements are:
+
+* TCP-MD5 requires 64-bit Linux
+* TSDR has extended requirements for external databases
+* Persistence has extended requirements for external databases
+* SFC requires addition features for certain configurations
+* SXP depends on TCP-MD5 on thus requires 64-bit Linux
+* SNBI has requirements for Linux and Docker
+* OpFlex requires Linux
+* DLUX requires a modern web browser to view the UI
+* AAA when using federation has additional requirements for external tools
+* VTN has components which require Linux
+
+For Development
+^^^^^^^^^^^^^^^
+
+OpenDaylight is written primarily in Java project and primarily uses
+Maven as a build tool Consequently the two main requirements to develop
+projects within OpenDaylight are:
+
+* A Java 8-compliant JDK
+* Maven 3.1.1 or later
+
+Applications and tools built on top of OpenDaylight using it's REST
+APIs should have no special requirements beyond whatever is needed to
+run the application or tool and make the REST calls.
+
+In some places, OpenDaylight makes use of the Xtend language. While
+Maven will download the appropriate tools to build this, additional
+plugins may be required for IDE support.
+
+The projects with additional requirements for execution typically have
+similar or more extensive additional requirements for development. See
+the project-specific release notes for details.
+
+Known Issues and Limitations
+----------------------------
+
+Other than as noted in project-specific release notes, we know of the
+following limitations:
+
+* Migration from Helium, Lithium and Beryllium to Boron has not been
+ extensively tested. The per-project release notes include migration and
+ compatibility information when it is known.
+* There are scales beyond which the controller has been unreliable when
+ collecting flow statistics from OpenFlow switches. In tests, these
+ issues became apparent when managing thousands of OpenFlow
+ switches, however this may vary depending on deployment and use cases.
+
+.. _proj_rel_notes:
+
+Project-specific Release Notes
+------------------------------
+
+For the release notes of individual projects, please see the following pages on the OpenDaylight Wiki.
+
+TBD: add Boron release notes
+
+* Authentication, Authorization and Accounting (AAA_)
+* ALTO_
+* BGPCEP_
+* Controller_
+* Control And Provisioning of Wireless Access Points (CAPWAP_)
+* Identification and Driver Management (DIDM_)
+* DLUX_
+* FaaS_
+* Group_Based_Policy_ (GPB)
+* Internet of Things Data Management (IoTDM_)
+* L2_Switch_
+* Link Aggregation Control Protocol (LACP_)
+* LISP_Flow_Mapping_
+* MDSAL_
+* NEMO_
+* NETCONF_
+* NetIDE_
+* NeXt_
+* Network Intent Composition (NIC_)
+* Neutron_Northbound_
+* OF-Config_
+* OpFlex_
+* OpenFlow_Plugin_
+* OpenFlow_Protocol_Library_
+* OVSDB_Netvirt_
+* Packet_Cable_ / PCMM
+* SDN_Interface_Application_
+* Secure Network Bootstrapping Infrastructure (SNBI_)
+* SNMP4SDN_
+* SNMP_Plugin_
+* Secure tag eXchange Protocol (SXP_)
+* Service Function Chaining (SFC_)
+* TCPMD5_
+* Time Series Data Repository (TSDR_)
+* Table Type Patterns (TTP_)
+* Topology_Processing_Framework_
+* Unified Secure Channel (USC_)
+* VPN_Service_
+* Virtual Tenant Network (VTN_)
+* YANG_Tools_
+
+Projects without Release Notes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The following projects participated in Boron, but intentionally do not have release notes.
+
+* **Documentation Project** produced this and the other downloadable documentation
+* **Integration Group** hosted the OpenDaylight-wide tests and main release distribution
+* **Release Engineering - autorelease** was used to build the Boron release artifacts and including the main release download.
+
+.. _AAA: https://wiki.opendaylight.org/view/AAA:Beryllium_Release_Notes
+.. _ALTO: https://wiki.opendaylight.org/view/ALTO:Beryllium:Release_Notes
+.. _BGPCEP: https://wiki.opendaylight.org/view/BGP_LS_PCEP:Beryllium_Release_Notes
+.. _CAPWAP: https://wiki.opendaylight.org/view/CAPWAP:Beryllium:Release_Notes
+.. _Controller: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Beryllium:Release_Notes
+.. _DIDM: https://wiki.opendaylight.org/view/DIDM:_Beryllium_Release_Notes
+.. _DLUX: https://wiki.opendaylight.org/view/OpenDaylight_DLUX:Beryllium:Release_Notes
+.. _FaaS: https://wiki.opendaylight.org/view/FaaS:Beryllium_Release_Notes
+.. _Group_Based_Policy: https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Releases/Beryllium:Beryllium_Release_Notes
+.. _IoTDM: https://wiki.opendaylight.org/view/Iotdm:Beryllium_Release_Notes
+.. _L2_Switch: https://wiki.opendaylight.org/view/L2_Switch:Beryllium:Release_Notes
+.. _LACP: https://wiki.opendaylight.org/view/LACP:Beryllium:Release_Notes
+.. _LISP_Flow_Mapping: https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Beryllium_Release_Notes
+.. _MDSAL: https://wiki.opendaylight.org/view/MD-SAL:Beryllium:Release_Notes
+.. _NEMO: https://wiki.opendaylight.org/view/NEMO:Beryllium:Release_Notes
+.. _NETCONF: https://wiki.opendaylight.org/view/OpenDaylight_NETCONF:Beryllium_Release_Notes
+.. _NetIDE: https://wiki.opendaylight.org/view/NetIDE:Release_Notes
+.. _NeXt: https://wiki.opendaylight.org/view/NeXt:Beryllium_Release_Notes
+.. _NIC: https://wiki.opendaylight.org/view/Network_Intent_Composition:Release_Notes
+.. _Neutron_Northbound: https://wiki.opendaylight.org/view/NeutronNorthbound:Beryllium:Release_Notes
+.. _OF-Config: https://wiki.opendaylight.org/view/OF-CONFIG:Beryllium:Release_Notes
+.. _OpFlex: https://wiki.opendaylight.org/view/OpFlex:Beryllium_Release_Notes
+.. _OpenFlow_Plugin: https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Beryllium_Release_Notes
+.. _OpenFlow_Protocol_Library: https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Release_Notes:Beryllium_Release_Notes
+.. _OVSDB_Netvirt: https://wiki.opendaylight.org/view/OpenDaylight_OVSDB:Beryllium_Release_Notes
+.. _Packet_Cable: https://wiki.opendaylight.org/view/PacketCablePCMM:BerylliumReleaseNotes
+.. _SDN_Interface_Application: https://wiki.opendaylight.org/view/ODL-SDNi:Beryllium_Release_Notes
+.. _SNBI: https://wiki.opendaylight.org/view/SNBI_Berrylium_Release_Notes
+.. _SNMP4SDN: https://wiki.opendaylight.org/view/SNMP4SDN:Beryllium_Release_Note
+.. _SNMP_Plugin: https://wiki.opendaylight.org/view/SNMP_Plugin:SNMP_Plugin:Beryllium_Release_Notes
+.. _SXP: https://wiki.opendaylight.org/view/SXP:Beryllium:Release_Notes
+.. _SFC: https://wiki.opendaylight.org/view/Service_Function_Chaining:Beryllium_Release_Notes
+.. _TCPMD5: https://wiki.opendaylight.org/view/TCPMD5:Beryllium_Release_Notes
+.. _TSDR: https://wiki.opendaylight.org/view/TSDR:Beryllium:Release_Notes
+.. _TTP: https://wiki.opendaylight.org/view/Table_Type_Patterns/Beryllium/Release_Notes
+.. _Topology_Processing_Framework: https://wiki.opendaylight.org/view/Topology_Processing_Framework:BERYLLIUM_Release_Notes
+.. _USC: https://wiki.opendaylight.org/view/USC:Beryllium:Release_Notes
+.. _VPN_Service: https://wiki.opendaylight.org/view/Vpnservice:Beryllium_Release_Notes
+.. _VTN: https://wiki.opendaylight.org/view/VTN:Beryllium:Release_Notes
+.. _YANG_Tools: https://wiki.opendaylight.org/view/YANG_Tools:Beryllium:Release_Notes
-== Security Considerations
+Security Considerations
+=======================
This document discusses the various security issues that might affect
OpenDaylight. The document also lists specific recommendations to
OpenDaylight, and if necessary, contact the Security Response Team,
which is tasked with identifying and resolving security threats.
-=== Overview of OpenDaylight Security
+Overview of OpenDaylight Security
+---------------------------------
There are many different kinds of security vulnerabilities that could affect
an OpenDaylight deployment, but this guide focuses on those where (a) the
device other than the one running OpenDaylight where the attack does not have
valid credentials to access the OpenDaylight deployment.
-//* *Code vulnerability*: This is defined as the vulnerability that arises
-//because of malicious human access to the applications and services that define
-//your business. With the increased usage of cloud and virtualized solutions,
-//there has been a rise in newer types of security threats. Your users require
-//access to data from anywhere and at any time. At present, there are a number
-//of recommended security strategies for your datacenter. However, with the
-//disparity of hardware vendors used across cloud services, it is difficult to
-//state with complete certainty that virtualized data centers are completely
-//secured. Access vulnerability, thus, is not a hallmark particular to
-//OpenDaylight, but to all services and businesses that run on the cloud.
-
The rest of this document gives specific recommendations for deploying
OpenDaylight in a secure manner, but first we highlight some high-level
security advantages of OpenDaylight.
them to make better decisions faster. At the same time,
centralization of network control can be an advantage only if access to that
control is secure.
-+
-NOTE: While both previous advantages improve security, they also make
- an OpenDaylight deployment an attractive target for attack making
- understanding these security considerations even more important.
-+
+
+ .. note:: While both previous advantages improve security, they also make
+ an OpenDaylight deployment an attractive target for attack making
+ understanding these security considerations even more important.
+
* The ability to more rapidly evolve southbound protocols and how they are used
provides more and faster mechanisms to enact appropriate security mitigations
and remediations.
* OpenDaylight has a history of rapidly addressing known vulnerabilities and
a well-defined process for reporting and dealing with them.
-=== OpenDaylight Security Resources
+OpenDaylight Security Resources
+-------------------------------
* If you have any security issues, you can send a mail to
-*security@lists.opendaylight.org*.
+ *security@lists.opendaylight.org*.
* For the list of current OpenDaylight security issues that are either being
-fixed or resolved, refer to
-https://wiki.opendaylight.org/view/Security_Advisories.
+ fixed or resolved, refer to
+ https://wiki.opendaylight.org/view/Security_Advisories.
* To learn more about the OpenDaylight security issues policies and procedure,
-refer to
-https://wiki.opendaylight.org/view/Security:Main
+ refer to https://wiki.opendaylight.org/view/Security:Main
-=== Deployment Recommendations
+Deployment Recommendations
+--------------------------
We recommend that you follow the deployment guidelines in setting up
OpenDaylight to minimize security threats.
* Separate the data network (that connects devices using the network) from the
management network (that connects the network devices to OpenDaylight).
-+
-NOTE: Deploying OpenDaylight on a separate, private management network does not
- eliminate threats, but only mitigates them. By construction, some
- messages must flow from the data network to the management network, e.g.,
- OpenFlow +packet_in+ messages, and these create an attack surface even if
- it is a small one.
-+
+
+ .. note:: Deploying OpenDaylight on a separate, private management network does not
+ eliminate threats, but only mitigates them. By construction, some
+ messages must flow from the data network to the management network, e.g.,
+ OpenFlow *packet_in* messages, and these create an attack surface even if
+ it is a small one.
+
* Implement an authentication policy for devices that connect to both the data
and management network. These are the devices which bridge, likely untrusted,
traffic from the data network to the management network.
-=== Securing OSGi bundles
+Securing OSGi bundles
+---------------------
OSGi is a Java-specific framework that improves the way that Java classes
interact within a single JVM. It provides an enhanced version of the
security model to add the following features:
* A set of OSGi-specific permission types, such as one that grants the right
-to register an OSGi service or get an OSGi service from the service registry.
+ to register an OSGi service or get an OSGi service from the service registry.
* The ability to dynamically modify permissions at runtime. This includes the
-ability to specify permissions by using code rather than a text configuration
-file.
+ ability to specify permissions by using code rather than a text configuration
+ file.
* A flexible predicate-based approach to determining which rules are
-applicable to which *ProtectionDomain*. This approach is much more powerful
-than the standard Java security policy which can only grant rights based on a
-jarfile URL or class signature. A few standard predicates are provided,
-including selecting rules based upon bundle symbolic-name.
+ applicable to which *ProtectionDomain*. This approach is much more powerful
+ than the standard Java security policy which can only grant rights based on a
+ jarfile URL or class signature. A few standard predicates are provided,
+ including selecting rules based upon bundle symbolic-name.
* Support for bundle *local permissions* policies with optional further
-constraints such as *DENY* operations. Most of this functionality is accessed
-by using the *OSGi ConditionalPermissionAdmin* service which is part of the
-OSGi core and can be obtained from the OSGi service registry. The
-+ConditionalPermissionAdmin+ API replaces the earlier *PermissionAdmin* API.
+ constraints such as *DENY* operations. Most of this functionality is accessed
+ by using the *OSGi ConditionalPermissionAdmin* service which is part of the
+ OSGi core and can be obtained from the OSGi service registry. The
+ *ConditionalPermissionAdmin* API replaces the earlier *PermissionAdmin* API.
For more information, refer to http://www.osgi.org/Main/HomePage.
-=== Securing the Karaf container
+Securing the Karaf container
+----------------------------
Apache Karaf is a OSGi-based runtime platform which provides a lightweight
container for OpenDaylight and applications. Apache Karaf uses
however they can be disabled by using various configuration alterations. These
configuration options may be applied to the OpenDaylight Karaf distribution.
-NOTE: Refer to the following list of publications for more information on
-implementing security for the Karaf container.
+.. note:: Refer to the following list of publications for more information on
+ implementing security for the Karaf container.
* For role-based JMX administration, refer to
-http://karaf.apache.org/manual/latest/users-guide/monitoring.html.
+ http://karaf.apache.org/manual/latest/users-guide/monitoring.html.
* For remote SSH access configuration, refer to
-http://karaf.apache.org/manual/latest/users-guide/remote.html.
+ http://karaf.apache.org/manual/latest/users-guide/remote.html.
* For WebConsole access, refer to
-http://karaf.apache.org/manual/latest/users-guide/webconsole.html.
+ http://karaf.apache.org/manual/latest/users-guide/webconsole.html.
* For Karaf security features, refer to
-http://karaf.apache.org/manual/latest/developers-guide/security-framework.html.
+ http://karaf.apache.org/manual/latest/developers-guide/security-framework.html.
-==== Disabling the remote shutdown port
+Disabling the remote shutdown port
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You can lock down your deployment post installation. Set
-karaf.shutdown.port=-1 in +etc/custom.properties or etc/config.properties+ to
+``karaf.shutdown.port=-1`` in ``etc/custom.properties`` or ``etc/config.properties`` to
disable the remote shutdown port.
-=== Securing Southbound Plugins
+Securing Southbound Plugins
+---------------------------
Many individual southbound plugins provide mechanisms to secure their
communication with network devices. For example, the OpenFlow plugin supports
When deploying OpenDaylight, you should carefully investigate the secure
mechanisms to connect to devices using the relevant plugins.
-=== Securing OpenDaylight using AAA
+Securing OpenDaylight using AAA
+-------------------------------
AAA stands for Authentication, Authorization, and Accounting. All three of
can help improve the security posture of and OpenDaylight deployment. In this
per-project release notes.
By default, OpenDaylight has only one user account with the username and
-password _admin_. This should be changed before deploying OpenDaylight.
+password *admin*. This should be changed before deploying OpenDaylight.
-=== Security Considerations for Clustering
+Security Considerations for Clustering
+--------------------------------------
While OpenDaylight clustering provides many benefits including high
availability, scale-out performance, and data durability, it also opens a new
Welcome to the OpenDaylight Handbook!
=====================================
+This handbook provides details on various aspects of OpenDaylight from the user
+guides to the developer guides and tries to act as a single point of contact
+for all documentation related articles in OpenDaylight. If you would like to
+contribute to the Handbook please refer to the :ref:`documentation-guide`.
+
Contents:
.. toctree::
- :maxdepth: 2
+ :maxdepth: 1
+
getting-started-guide/index
opendaylight-with-openstack/index
submodules/releng/builder/docs/index
+ submodules/integration/test/docs/index
+ documentation
Indices and tables
==================
--- /dev/null
+Subproject commit 945626a6c0413a6e0af1c5bbc7eae59a77bd18cd
-Subproject commit 7d68c05bbff3d25f7e8ef52f23d54aeadbd435c1
+Subproject commit 12dddebb9ac20a9e4ba9ae72596d28052c4bf043
== DIDM Developer Guide
=== Overview
+
The Device Identification and Driver Management (DIDM) project addresses the
need to provide device-specific functionality. Device-specific functionality is
code that performs a feature, and the code is knowledgeable of the capability
determine this association requires the ability to identify the device type.
=== DIDM Architecture
+
The DIDM project creates the infrastructure to support the following functions:
* *Discovery* - Determination that a device exists in the controller
support the APIs defined by the RPCs. There may be different Driver
implementations for different device types.
-//TODO: Add more info and diagram.
-//
-//=== Key APIs and Interfaces
-//TODO
-//
-//=== API Reference Documentation
-//TODO: Provide links to JavaDoc, REST API documentation, etc.
+
+=== Key APIs and Interfaces
+
+The Beryllium release includes a flow mod driver for the HP 3800.
+This driver adjusts the flows and push the same to the device.
+This API takes the flow to be adjusted as input and displays the adjusted flow as output in the REST output container.
+Here is the REST API to adjust and push flows to HP 3800 device:
+
+----
+http://<CONTROLLER-IP:8181>/restconf/operations/openflow-feature:adjust-flow
+----
+
+Here is an example of an ARP flow and how it gets adjusted and pushed to device HP3800:
+
+.adjust-flow input
+----
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<input xmlns="urn:opendaylight:params:xml:ns:yang:didm:drivers:openflow" xmlns:opendaylight-inventory="urn:opendaylight:inventory">
+ <node>/opendaylight-inventory:nodes/opendaylight-inventory:node[opendaylight-inventory:id='openflow:673249119553088']</node>
+ <flow>
+ <match>
+ <ethernet-match>
+ <ethernet-type>
+ <type>2054</type>
+ </ethernet-type>
+ </ethernet-match>
+ </match>
+ <flags>SEND_FLOW_REM</flags>
+ <priority>0</priority>
+ <flow-name>ARP_FLOW</flow-name>
+ <instructions>
+ <instruction>
+ <order>0</order>
+ <apply-actions>
+ <action>
+ <order>0</order>
+ <output-action>
+ <output-node-connector>CONTROLLER</output-node-connector>
+ <max-length>65535</max-length>
+ </output-action>
+ </action>
+ <action>
+ <order>1</order>
+ <output-action>
+ <output-node-connector>NORMAL</output-node-connector>
+ <max-length>65535</max-length>
+ </output-action>
+ </action>
+ </apply-actions>
+ </instruction>
+ </instructions>
+ <idle-timeout>180</idle-timeout>
+ <hard-timeout>1800</hard-timeout>
+ <cookie>10</cookie>
+ </flow>
+</input>
+----
+
+In the output, you can see that the table ID has been identified for the given
+flow and two flow mods are created as a result of adjustment. The first one is
+to catch ARP packets in Hardware table 100 with an action to goto table 200.
+The second flow mod is in table 200 with actions: output normal and output
+controller.
+
+.adjust-flow output
+----
+{
+ "output": {
+ "flow": [
+ {
+ "idle-timeout": 180,
+ "instructions": {
+ "instruction": [
+ {
+ "order": 0,
+ "apply-actions": {
+ "action": [
+ {
+ "order": 1,
+ "output-action": {
+ "output-node-connector": "NORMAL",
+ "max-length": 65535
+ }
+ },
+ {
+ "order": 0,
+ "output-action": {
+ "output-node-connector": "CONTROLLER",
+ "max-length": 65535
+ }
+ }
+ ]
+ }
+ }
+ ]
+ },
+ "strict": false,
+ "table_id": 200,
+ "flags": "SEND_FLOW_REM",
+ "cookie": 10,
+ "hard-timeout": 1800,
+ "match": {
+ "ethernet-match": {
+ "ethernet-type": {
+ "type": 2054
+ }
+ }
+ },
+ "flow-name": "ARP_FLOW",
+ "priority": 0
+ },
+ {
+ "idle-timeout": 180,
+ "instructions": {
+ "instruction": [
+ {
+ "order": 0,
+ "go-to-table": {
+ "table_id": 200
+ }
+ }
+ ]
+ },
+ "strict": false,
+ "table_id": 100,
+ "flags": "SEND_FLOW_REM",
+ "cookie": 10,
+ "hard-timeout": 1800,
+ "match": {},
+ "flow-name": "ARP_FLOW",
+ "priority": 0
+ }
+ ]
+ }
+}
+----
+
+=== API Reference Documentation
+Go to http://${CONTROLLER-IP}:8181/apidoc/explorer/index.html, and look under DIDM section
+to see all the available REST calls and tables
+++ /dev/null
-<project xmlns="http://maven.apache.org/POM/4.0.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
- <parent>
- <groupId>org.opendaylight.docs</groupId>
- <artifactId>manuals</artifactId>
- <version>0.3.0-SNAPSHOT</version>
- <relativePath>../pom.xml</relativePath>
- </parent>
- <modelVersion>4.0.0</modelVersion>
- <artifactId>getting-started-guide</artifactId>
- <packaging>jar</packaging>
- <name>OpenDaylight Docs - Manuals - Getting Started Guide</name>
- <properties>
- <!-- This is set by Jenkins according to the branch. -->
- <release.path.name>local</release.path.name>
- <comments.enabled>1</comments.enabled>
- <bookname>bk-getting-started-guide</bookname>
- </properties>
- <!-- ################################################ -->
- <!-- USE "mvn clean generate-sources" to run this POM -->
- <!-- ################################################ -->
- <build>
- <plugins>
- <plugin>
- <groupId>org.asciidoctor</groupId>
- <artifactId>asciidoctor-maven-plugin</artifactId>
- <version>${asciidoctor.version}</version>
- <executions>
- <execution>
- <id>output-docbook</id>
- <phase>generate-sources</phase>
- <goals>
- <goal>process-asciidoc</goal>
- </goals>
- <configuration>
- <backend>docbook5</backend>
- <doctype>book</doctype>
- </configuration>
- </execution>
- </executions>
- <configuration>
- <sourceDirectory>src/main/asciidoc</sourceDirectory>
- <sourceDocumentName>${bookname}.adoc</sourceDocumentName>
- <imagesDir>./images</imagesDir>
- </configuration>
- </plugin>
- <plugin>
- <artifactId>maven-resources-plugin</artifactId>
- <version>2.6</version>
- <executions>
- <execution>
- <id>copy-resources</id>
- <phase>generate-resources</phase>
- <goals>
- <goal>copy-resources</goal>
- </goals>
- <configuration>
- <outputDirectory>${basedir}/target/generated-docs</outputDirectory>
- <resources>
- <resource>
- <directory>src/main/resources</directory>
- <includes>
- <include>**/*.*</include>
- </includes>
- </resource>
- </resources>
- </configuration>
- </execution>
- </executions>
- </plugin>
- <plugin>
- <groupId>com.inocybe.api</groupId>
- <artifactId>sdndocs-maven-plugin</artifactId>
- <version>0.1.0</version>
- <executions>
- <execution>
- <id>generate-webhelp</id>
- <goals>
- <goal>generate-webhelp</goal>
- </goals>
- <phase>compile</phase>
- <configuration>
- <profileAudience>enduser</profileAudience>
- <includes>target/generated-docs/${bookname}.xml</includes>
- <generateToc>
- appendix toc,title
- article/appendix nop
- article toc,title
- book toc,title,figure,table,example,equation
- chapter toc,title
- section toc
- part toc,title
- qandadiv toc
- qandaset toc
- reference toc,title
- set toc,title
- </generateToc>
- <webhelpDirname>${bookname}</webhelpDirname>
- <pdfFilenameBase>${bookname}</pdfFilenameBase>
- </configuration>
- </execution>
- </executions>
- <configuration>
- <profileAudience>enduser</profileAudience>
- <chapterAutolabel>1</chapterAutolabel>
- <sectionAutolabel>0</sectionAutolabel>
- <tocSectionDepth>1</tocSectionDepth>
- <formalProcedures>0</formalProcedures>
- <highlightSource>false</highlightSource>
- <xincludeSupported>true</xincludeSupported>
- <showXslMessages>true</showXslMessages>
- <sourceDirectory>.</sourceDirectory>
- <feedbackEmail>mlemay@inocybe.com</feedbackEmail>
- <branding>opendaylight</branding>
- <coverLogoLeft>2.6in</coverLogoLeft>
-<!-- <enableDisqus>${comments.enabled}</enableDisqus>
- <disqusShortname>os-user-guide</disqusShortname>
- <enableGoogleAnalytics>1</enableGoogleAnalytics>
- <googleAnalyticsId>UA-17511903-1</googleAnalyticsId>
- --> <suppressFooterNavigation>0</suppressFooterNavigation>
- <canonicalUrlBase>http://docs.opendaylight.org/user-guide/content/</canonicalUrlBase>
- <glossaryCollection>${basedir}/../glossary/glossary-terms.xml</glossaryCollection>
- </configuration>
- </plugin>
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-site-plugin</artifactId>
- <version>3.1</version>
- <configuration>
- <inputDirectory>${project.build.directory}/docbkx/webhelp</inputDirectory>
- </configuration>
- <dependencies>
- <dependency>
- <groupId>org.apache.maven.wagon</groupId>
- <artifactId>wagon-webdav-jackrabbit</artifactId>
- <version>2.2</version>
- </dependency>
- <dependency>
- <groupId>org.slf4j</groupId>
- <artifactId>slf4j-api</artifactId>
- <version>1.6.1</version>
- </dependency>
- </dependencies>
- </plugin>
- </plugins>
- </build>
-</project>
+++ /dev/null
-
- <author>
- <personname>
- <firstname>OpenDaylight</firstname>
- <surname>Community</surname>
- </personname>
- <email>documentation@opendaylight.org</email>
- <affiliation>
- <orgname>Linux Foundation</orgname>
- </affiliation>
- </author>
- <copyright>
- <year>2015</year>
- <holder>Linux Foundation</holder>
- </copyright>
- <releaseinfo>Beryllium</releaseinfo>
- <productname>OpenDaylight</productname>
- <pubdate></pubdate>
- <legalnotice role="license">
- <para> This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at <link xlink:href="http://www.eclipse.org/legal/epl-v10.html"/></para>
- </legalnotice>
- <abstract>
- <para>This guide describes how to get started with OpenDaylight.</para>
- </abstract>
- <revhistory>
- <revision>
- <date>2014-07-16</date>
- <revdescription>
- <itemizedlist spacing="compact">
- <listitem>
- <para>Initial Guide Creation</para>
- </listitem>
- </itemizedlist>
- </revdescription>
- </revision>
- </revhistory>
-
+++ /dev/null
-[[bk-getting-started-guide]]
-= OpenDaylight Getting Started Guide
-:docinfo:
-
-//////////////////////////
-// BEGIN COMMENT
-[dedication]
-Example Dedication
-------------------
-Optional dedication.
-
-This document is an AsciiDoc book skeleton containing briefly
-annotated example elements plus a couple of example index entries and
-footnotes.
-
-Books are normally used to generate DocBook markup and the titles of
-the preface, appendix, bibliography, glossary and index sections are
-significant ('specialsections').
-
-
-[preface]
-Example Preface
----------------
-Optional preface.
-
-Preface Sub-section
-~~~~~~~~~~~~~~~~~~~
-Preface sub-section body.
-
-Using OpenDaylight
---------------------------
-
-[partintro]
-.Optional part introduction title
---
-Optional part introduction goes here.
---
-
-OpenDaylight Add-ons
--------------------------
-
-[partintro]
-.Optional part introduction title
---
-Optional part introduction goes here.
---
-// END COMMENT
-//////////////////////////
-
-//////////////////////////
-// BEGIN COMMENT
-Please note and leave the blank line between include statements here.
-
-It is a defensive measure to prevent individual projects' .adoc files
-from eating the next section if they forget to leave a blank line at
-the end of their file.
-// END COMMENT
-//////////////////////////
-
-include::release-notes.adoc[OpenDaylight Release Notes]
-
-include::general_installation.adoc[]
-
-= Getting to know OpenDaylight
-
-include::ch-introduction.adoc[]
-
-include::ch-dlux.adoc[]
-
-include::ch-xsql-commands.adoc[]
-
-include::ch-clustering.adoc[]
-
-include::chapter_security_considerations.adoc[]
-
-= Project-specific Installation Guides
-
-include::opflex/agent-ovs-install.adoc[]
-
-include::ovsdb/ovsdb-install.adoc[]
-
-include::tsdr/tsdr-installation-guide.adoc[]
-
-include::vtn/vtn-install.adoc[]
-
-:numbered!:
-
-//////////////////////////
-// BEGIN COMMENT
-[appendix]
-Example Appendix
-----------------
-One or more optional appendixes go here at section level 1.
-
-Appendix Sub-section
-~~~~~~~~~~~~~~~~~~~
-Sub-section body.
-
-
-[glossary]
-Example Glossary
-----------------
-Glossaries are optional. Glossaries entries are an example of a style
-of AsciiDoc labeled lists.
-
-[glossary]
-A glossary term::
- The corresponding (indented) definition.
-
-A second glossary term::
- The corresponding (indented) definition.
-
-
-[colophon]
-Example Colophon
-----------------
-Text at the end of a book describing facts about its production.
-
-
-[index]
-Example Index
--------------
-// END COMMENT
-//////////////////////////
-
-////////////////////////////////////////////////////////////////
-The index is normally left completely empty, it's contents being
-generated automatically by the DocBook toolchain.
-////////////////////////////////////////////////////////////////
-
+++ /dev/null
-[preface]
-== OpenDaylight Overview
-The OpenDaylight project is a collaborative open source project that
-aims to accelerate adoption of Software-Defined Networking (SDN) and
-Network Functions Virtualization (NFV) with a transparent approach that
-fosters new innovation.
-
-OpenDaylight mainly consists of software designed to be run on top of a
-Java Virtual Machine (JVM) and can be run on any operating system and
-hardware as there is a Java Runtime Environment (JRE) available for it.
-
-// TODO: uncomment the following lines when we have them to the point we think they're useful.
-// OpenDaylight makes use of the following third-party tools:
-//
-// * *Maven*: OpenDaylight uses Maven for easier build automation. Maven uses pom.xml
-// (Project Object Model) to script the dependencies between bundles.
-//
-// * *OSGi*: OSGi framework is the back-end of OpenDaylight as it allows dynamically
-// loading bundles and packages JAR files, and binding bundles together for exchanging
-// information.
-//
-// * *JAVA interfaces*: Java interfaces are usually generated by compiling the YANG project. Java interfaces are used for event listening, specifications, and forming
-// patterns. This is the main way in which specific bundles implement call-back functions for events and also to indicate awareness of specific state.
-//
-// * *REST APIs*: Most of the REST APIs in OpenDaylight are defined using YANG tools and are RESTCONF APIs.
-//
-// * *Karaf*: TBD
-
-For a more detailed information about OpenDaylight, see the and _OpenDaylight User Guie_, _OpenDaylight
-Developer Guide_.
-
+++ /dev/null
-== The First Chapter
-
-Chapters can contain sub-sections nested up to three deep.
-footnote:[An example footnote.]
-indexterm:[Example index entry]
-
-Chapters can have their own bibliography, glossary and index.
-
-And now for something completely different: ((monkeys)), lions and
-tigers (Bengal and Siberian) using the alternative syntax index
-entries.
-(((Big cats,Lions)))
-(((Big cats,Tigers,Bengal Tiger)))
-(((Big cats,Tigers,Siberian Tiger)))
-Note that multi-entry terms generate separate index entries.
-
-Here are a couple of image examples: an image:smallnew.png[]
-example inline image followed by an example block image:
-
-.Tiger block image
-image::tiger.png[Tiger image]
-
-Followed by an example table:
-
-.An example table
-[width="60%",options="header"]
-|==============================================
-| Option | Description
-| -a 'USER GROUP' | Add 'USER' to 'GROUP'.
-| -R 'GROUP' | Disables access to 'GROUP'.
-|==============================================
-
-.An example example
-===============================================
-Lorum ipum...
-===============================================
-
-[[X1]]
-=== Sub-section with Anchor
-
-Sub-section at level 2.
-
-==== Chapter Sub-section
-
-Sub-section at level 3.
-
-===== Chapter Sub-section
-
-Sub-section at level 4.
-
-This is the maximum sub-section depth supported by the distributed
-AsciiDoc configuration.
-footnote:[A second example footnote.]
-
-
-== The Second Chapter
-
-An example link to anchor at start of the <<X1,first sub-section>>.
-indexterm:[Second example index entry]
-
-
-
-== The Third Chapter
-
-Book chapters are at level 1 and can contain sub-sections.
-
+++ /dev/null
-
-=== Installing from Zip
-
-Installing from zip is an easy way to get started with OpenDaylight. When installing from zip, the process is as simple as running the completely packaged environment. However unlike official distribution packages OpenDaylight will have to be upgraded manually after each release when installing from zip files.
-
-==== Prerequisites
-
-In order to be able to install and run the zip file the following prerequisites have to be fulfilled:
-
-* A Java 1.7 compatible JDK or JRE have to be installed (i.e. Oracle JDK 1.7 or OpenJDK 1.7)
-In general, OpenDaylight requires appropriate setting of the JAVA_HOME directory
-More information can be found in the OpenDaylight Hydrogen Release Notes
-On some platforms, there are known issues with Oracle Java 1.7.0_21 and 1.7.0_25, but 1.7.0_45 and 1.7.0_51 have worked fine
-
-==== Getting the Zip File
-
-You can find the OpenDaylight Hydrogen Release Base Edition zip file on the download page here:
-
-http://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/integration/distributions-base/0.1.1/distributions-base-0.1.1-osgipackage.zip
-
-Understanding Structure
-The main content of OpenDaylight Hydrogen is in a directory called opendaylight, where you will see the following files:
-run.sh
-launches OpenDaylight on Linux/Mac/Unix systems
-run.bat
-launches OpenDaylight on Windows systems
-version.properties
-indicates the build version
-configuration
-basic initialization files (internal to OpenDaylight)
-lib
-Java libraries
-Running OpenDaylight
-To launch OpenDaylight follow these easy steps from the root opendaylight directory
-Enter ./run.sh or ./run.bat with administrator privileges to launch OpenDaylight.
-Starting
-To run OpenDaylight in background enter ./run.sh -start with administrator priviledges.
-Stopping
-To stop OpenDaylight, which is running in background enter ./run.sh -stop with administrator priviledges.
-Status
-In order to see the status of OpenDaylight, enter ./run.sh -status. It will show whether it is running or has been stopped.
-Navigate to http://<ip-address-of-machine-where-you-ran-opendaylight>:8080 to open the web interface, then use the following credentials to log in:
-User: admin
-Password: admin
-If you are running OpenDaylight on the same machine as your browser, you can browse to http://localhost:8080 or http://127.0.0.1:8080 to avoid needing to know the IP address of the machine you are using.
-You will now have a completely running OpenDaylight installation.
+++ /dev/null
-== Getting and Installing OpenDaylight
-
-=== Downloading and installing OpenDaylight
-
-The default distribution can be found on the OpenDaylight software
-download page: http://www.opendaylight.org/software/downloads
-
-The Karaf distribution has no features enabled by default. However, all
-of the features are available to be installed.
-
-NOTE: For compatibility reasons, you cannot enable all the features
-simultaneously. We try to document known incompatibilities
-<<_installing_the_components,below>>.
-
-==== Running the karaf distribution
-To run the Karaf distribution:
-
-. Unzip the zip file.
-. Navigate to the directory.
-. run `./bin/karaf`.
-
-For Example:
-
-[frame="none"]
-|===
-a|
-----
-$ ls distribution-karaf-0.4.0-Beryllium.zip
-distribution-karaf-0.4.0-Beryllium.zip
-$ unzip distribution-karaf-0.4.0-Beryllium.zip
-Archive: distribution-karaf-0.4.0-Beryllium.zip
- creating: distribution-karaf-0.4.0-Beryllium/
- creating: distribution-karaf-0.4.0-Beryllium/configuration/
- creating: distribution-karaf-0.4.0-Beryllium/data/
- creating: distribution-karaf-0.4.0-Beryllium/data/tmp/
- creating: distribution-karaf-0.4.0-Beryllium/deploy/
- creating: distribution-karaf-0.4.0-Beryllium/etc/
- creating: distribution-karaf-0.4.0-Beryllium/externalapps/
-...
- inflating: distribution-karaf-0.4.0-Beryllium/bin/start.bat
- inflating: distribution-karaf-0.4.0-Beryllium/bin/status.bat
- inflating: distribution-karaf-0.4.0-Beryllium/bin/stop.bat
-$ cd distribution-karaf-0.4.0-Beryllium
-$ ./bin/karaf
-
- ________ ________ .__ .__ .__ __
- \_____ \ ______ ____ ____ \______ \ _____ ___.__.\| \| \|__\| ____ \| \|___/ \|_
- / \| \\____ \_/ __ \ / \ \| \| \\__ \< \| \|\| \| \| \|/ ___\\| \| \ __\
- / \| \ \|_> > ___/\| \| \\| ` \/ __ \\___ \|\| \|_\| / /_/ > Y \ \|
- \_______ / __/ \___ >___\| /_______ (____ / ____\|\|____/__\___ /\|___\| /__\|
- \/\|__\| \/ \/ \/ \/\/ /_____/ \/
-
-
-----
-* Press *tab* for a list of available commands
-* Typing *[cmd] --help* will show help for a specific command.
-* Press *ctrl-d* or type *system:shutdown* or *logout* to shutdown OpenDaylight.
-|===
-
-=== Installing the components
-
-The section describes a list of components in OpenDaylight Beryllium and
-the relevant Karaf feature to install in order to enable that component.
-
-To install a feature use the following command:
------
-feature:install
------
-For Example:
-
------
-feature:install <feature-name>
------
-
-Multiple features can be installed using the following command:
-
------
-feature:install <feature1-name> <feature2-name> ... <featureN-name>
------
-
-.Beryllium Components
-[options="header",cols="18%,50%,18%,14%"]
-|====
-| Component Name | Component Description | Karaf feature name | Compatibility
-| ALTO | Enable support for Application-Layer Traffic Optimization | odl-alto-all | self+all
-| BGP | Enables support for BGP | odl-bgpcep-bgp-all | all
-| CAPWAP | Enables control of supported wireless APs | odl-capwap-ac-rest | all
-| DIDM | Device Identification and Driver Management | odl-didm-identification-api, odl-didm-identification, and odl-didm-drivers-api | all
-| Group Based Policy | Enable Endpoint Registry and Policy Repository REST APIs and associated functionality for Group Based Policy | odl-groupbasedpolicy-ofoverlay | self+all
-| Internet of Things Data Management | Enables support for the oneM2M specification | odl-iotdm-onem2m | all
-| L2 Switch | Provides L2 (Ethernet) forwarding across connected OppenFlow switches and support for host tracking | odl-l2switch-switch-ui | self+all
-| LACP | Enable support for the Link Aggregation Control Protocol | odl-lacp-ui | self+all
-| LISP Flow Mapping | Enable LISP control plane services including the mapping system services REST API and LISP protocol SB plugin | odl-lispflowmapping-all | all
-| MD-SAL Clustering | Provides support for operating a cluster of OpenDaylight instances | odl-mdsal-clustering | special
-| NETCONF over SSH | Provides support to manage NETCONF-enabled devices over SSH | odl-netconf-connector-ssh | all
-| Network Intent Composition | Enable support for high-level network control via intents | odl-nic-core | self+all
-| OVS Management | Enables OVS management using OVSDB plugin and its associated OVSDB northbound APIs | odl-ovsdb-all | all
-| OVSDB OpenStack Neutron | OpenStack Network Virtualization using OpenDaylight's OVSDB support | odl-ovsdb-openstack | self+all
-| OpFlex | Enables support for the OpFlex protocol | special (see user/developer guide) | all
-| OpenFlow Flow Programming | Enables discovery and control of OpenFlow switches and the topology between them | odl-openflowplugin-flow-services-ui | all
-| OpenFlow Table Type Patterns | Allows OpenFlow Table Type Patterns to be manually associated with network elements | odl-ttp-all | all
-| PCEP | Enables support for PCEP | odl-bgpcep-pcep-all | all
-| Packetcable PCMM | Enables flow-based dynamic QoS management of CMTS using in the DOCSIS infrastructure | odl-packetcable-all | self+all
-| Packetcable Policy Server | Enables support for the PacketCable policy server | odl-packetcable-policy-server-all | self+all
-| RESTCONF API Support | Enables REST API access to the MD-SAL including the data store | odl-restconf | all
-| SDN Interface | Provides support for interaction and sharing of state between (non-clustered) OpenDaylight instances | odl-sdninterfaceapp-all | all
-| SFC over L2 | Supports implementing SFC using Layer 2 forwarding | odl-sfcofl2 | self+all
-| SFC over LISP | Supports implementing SFC using LISP | odl-sfclisp | all
-| SFC over REST | Supports implementing SFC using REST CRUD operations on network elements | odl-sfc-sb-rest | all
-| SFC over VXLAN | Supports implementing SFC using VXLAN tunnels | odl-sfc-ovs | self+all
-| SNMP Plugin | Enables monitoring and control of network elements via SNMP | odl-snmp-plugin | all
-| SNMP4SDN | Enables OpenFlow-like control of network elements via SNMP | odl-snmp4sdn-all | all
-| SSSD Federated Authentication | Enable support for federated authentication using SSSD | odl-aaa-sssd-plugin | all
-| Secure Networking Bootstrap | Defines a SNBI domain and associated white lists of devices to be accommodated to the domain | odl-snbi-all | self+all
-| Secure tag eXchange Protocol (SXP) | Enables distribution of shared tags to network devices | odl-sxp-controller | all
-| Service Flow Chaining (SFC) | Enables support for applying chains of network services to certain traffic | odl-sfc-all | all
-| Time Series Data Repository (TSDR) | Enables historical tracking of OpenFlow statistics | odl-tsdr-all | self+all
-| Topology Processing Framework | Enables merged and filtered views of network topologies | odl-topoprocessing-framework | all
-| Unified Secure Channel (USC) | Enables support for secure, remote connections to network devices | odl-usc-channel-ui | all
-| VPN Service | Enables support for OpenStack VPNaaS | odl-vpnservice-core | all
-| VTN Manager | Enables Virtual Tenant Network support | odl-vtn-manager-rest | self+all
-| VTN Manager Neutron | Enables OpenStack Neutron support of VTN Manager | odl-vtn-manager-neutron | self+all
-|====
-
-In the table a compatibility value of *all* means that it can be run with other features. A value of *self+all* indicates that the feature can be installed with other features with a value of *all*, but may interact badly other features with a value of *self+all*.
-
-.Experimental Beryllium Components
-[options="header",cols="18%,50%,18%,14%"]
-|====
-| Component Name | Component Description | Karaf feature name | Compatibility
-| Persistence | Enables saving of data to external databases | odl-persistence-api | self+all
-| Reservation | Enables bandwidth calendaring using the TL1 protocol | odl-reservation-models | all
-|====
-
-==== Listing available features
-To find the complete list of Karaf features, run the following command:
-
-----
-feature:list
-----
-
-To list the installed Karaf features, run the following command:
-
-----
-feature:list -i
-----
-
-// Commenting out this section until we can actually provide some content.
-//
-// === Verifying your installation
-// TBD
-
-=== Installing support for REST APIs
-Most components that offer REST APIs will automatically load the RESTCONF API Support
-component, but if for whatever reason they seem to be missing, you can activate this
-support by installing the `odl-restconf` feature.
-
-// Commenting out this section until we can actually provide a tutorial that a
-// user could follow
-//
-// === Making RESTCONF calls
-// RESTCONF is a protocol that provides a programmatic interface over HTTP to access data that is defin
-// ed in a YANG model and stored in data stores defined in the NETCONF protocol.
-// RESTCONF protocol is implemented in `sal-rest-connector` artifact that is packed with the Karaf bundle.
-// For more information on the RESTCONF protocol, refer to http://tools.ietf.org/html/draft-bierman-net
-// conf-restconf-02
-//
-// RESTCONF allows access to datastores in the controller.
-// The datastores available are:
-//
-// * config - contains data inserted using controller
-// * operational - contains other data
-//
-// ==== Making a RESCONF call using cURL
-//
-// TBD
-
-// Commenting this out as it appears to be out of date and there is already
-// information about installing and using DLUX above.
-//
-//=== Installing the DLUX web interface
-//
-//The OpenDaylight web interface; DLUX, draws information from topology and host databases to display information about the topology of the network,
-//flow statistics, host locations. You can either use DLUX as a stand-alone plug-in or integrate with OpenDaylight.
-//To install DLUX as a standalone application, refer to https://wiki.opendaylight.org/view/OpenDaylight_DLUX:Setup_and_Run
-//To integrate with OpenDaylight you must enable DLUX Karaf feature. You can enable AD-SAL, MD-SAL and various other bundles within Karaf depending on the features you
-//would like to access using DLUX. Each feature can be enabled or disabled separately.
-//
-//[IMPORTANT]
-//Ensure that you have created a topology and enabled MD-SAL feature in the Karaf distribution before you use DLUX for network management.
-//For more information about enabling the Karaf features for DLUX, refer to https://wiki.opendaylight.org/view/OpenDaylight_DLUX:DLUX_Karaf_Feature
-
-=== Installing MD-SAL clustering
-The MD-SAL clustering feature has "special" compatibility criteria. You *must*
-install clustering, before other features are installed. To install clustering,
-run the following command on the Karaf CLI console:
-
-----
-feature:install odl-mdsal-clustering
-----
-
-// Commenting out this section until we can actually provide a tutorial that
-// walks through getting everything set up. Maybe we should just point to the
-// L2 Switch docs?
-//
-// === Getting started with OpenFlow and Mininet
-//
-// ==== Downloading and installing Mininet
-//
-// Mininet downloads are available at: http://mininet.org
-//
-// The OVS version must be 2.1 or earlier.
-//
-// The instructions for installation are available at: http://mininet.org.
-//
-// ===== Verifying mininet installation
-// To verify your mininet installation run the following command:
-// `test=pingall`
-//
-// ----
-// odluser@odl-vm:~\$ sudo mn --test=pingall
-// *** Creating network
-// *** Adding controller
-// *** Adding hosts:
-// h1 h2
-// *** Adding switches:
-// s1
-// *** Adding links:
-// (h1, s1) (h2, s1)
-// *** Configuring hosts
-// h1 h2
-// *** Starting controller
-// *** Starting 1 switches
-// s1 OVSswitch opts:
-// *** Ping: testing ping reachability
-// h1 -> h2
-// h2 -> h1
-// *** Results: 0% dropped (2/2 received)
-// *** Stopping 1 switches
-// s1 ..
-// *** Stopping 2 hosts
-// h1 h2
-// *** Stopping 1 controllers
-// c0
-// *** Done
-// completed in 0.541 seconds
-// ----
-//
-// ==== Enabling the OpenFlow plugin and L2 Switch
-//
-// To enable these features, run:
-//
-// ----
-// feature:install odl-l2switch-switch-ui
-// ----
-//
-// This will install the OpenFlow plugin and the L2 Switch application.
-//
-// ==== Running Mininet using OpenDaylight as the controller
-//
-// TODO
+++ /dev/null
-== AAA service
-
-Chapter on AAA service.
-
+++ /dev/null
-== Controller
-
-Chapter on the controller
-
+++ /dev/null
-== Defense4All
-
-For information on how to install Defense4All please see this page on the OpenDaylight here: https://wiki.opendaylight.org/view/Defense4All:Installation_Guide
\ No newline at end of file
+++ /dev/null
-== dLux
-
-Chapter on DLUX
-
+++ /dev/null
-== Group Based Policy
-
-Chapter on Group Based Policy
-
+++ /dev/null
-== L2 Switch
-
-Chapter on L2 Switch
-
+++ /dev/null
-== Lisp Flow Mapping
-
-Please see the OpenDaylight Developer's Guide for detailed instructions.
-
-
-
+++ /dev/null
-== ODL-SDNi
-
-Chapter on ODL-SDNi
-
-https://wiki.opendaylight.org/view/ODL-SDNiApp:Developer_Guide
-
+++ /dev/null
-== OpenFlow Protocol Library
-
-Chapter on OpenFlow protocol library
-
+++ /dev/null
-== OpenFlow Plugin
-
-Chapter on Open Flow Plugin
+++ /dev/null
-== Helium Overview
-
-add text and reference to helium project dependency diagram
-
+++ /dev/null
-== OVSDB
-
-Chapter on OVSDB
-
+++ /dev/null
-== PacketCable PCMM
-
-Once the karaf distribution is downloaded and running, it is suggested that you install the following features:
-
-* +odl-restconf+
-* +odl-l2switch-switch+
-* +odl-dlux-core+
-* +odl-mdsal-apidocs+
-* +odl-packetcable-all+
-
-This can be done as a single command at the Karaf CLI:
-
-+feature:install standard odl-restconf odl-l2switch-switch odl-dlux-core odl-mdsal-apidocs odl-packetcable-all+
-
-Technically, the +odl-dlux-core+ and +odl-mdsal-apidocs+ features are not required for operation, but they enable you to verify the installation has worked and provide REST interfaces.
+++ /dev/null
-== Plugin for OpenContrail
-
-Chapter on Southbound plugin to OpenContrail
-
-https://wiki.opendaylight.org/view/Southbound_plugin_to_the_OpenContrail_platform:Environment_Setup
+++ /dev/null
-== Service Function Chaining
-
-Chapter on Service Function Chaining
-
+++ /dev/null
-== Secure Network Bootstrapping Infrastructure
-
-Chapter on Secure Network Bootstrapping Infrastructure
-
+++ /dev/null
-== SNMP4SDN
-
-Chapter on SNMP for SDN
-
+++ /dev/null
-== Yang Tools \r
-\r
-=== Installation Overview\r
-Yang tools is a infrastructure project aiming to develop necessary tooling and libraries providing support for NETCONF and YANG for Java (JVM-language based) projects and applications.\r
-Yang tools is used for application such as Model Driven SAL for Controller (which uses YANG as the modeling language) and Netconf or OFConfig plugins. \r
-\r
-==== Installing the Project\r
-To configure your project and generate source code from YANG edit your projects *pom.xml* and add Opendaylight SNAPSHOT repository for snapshot releases (currently only snapshots are available). \r
-\r
-=== Adding Plugin Repositories \r
-==== Plugin Repository\r
-To add following plugin repositories for plugin use: +\r
-\r
-[literal]\r
-<pluginRepositories>\r
- <pluginRepository> \r
- <id>opendaylight-release</id>\r
- <name>opendaylight-release</name>\r
- <url>http://nexus.opendaylight.org/content/repositories/opendaylight.release/</url>\r
- </pluginRepository>\r
- <pluginRepository> \r
- <id>opendaylight-snapshot</id>\r
- <name>opendaylight-snapshot</name>\r
- <url>http://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/</url>\r
- </pluginRepository>\r
-</pluginRepositories>\r
-\r
-==== Dependency Repository\r
-\r
-To add repositories for required dependencies use: \r
-[literal]\r
-<repositories> \r
- <repository> \r
- <id>opendaylight-release</id>\r
- <name>opendaylight-release</name>\r
- <url>http://nexus.opendaylight.org/content/repositories/opendaylight.release/</url>\r
- </repository>\r
- <repository> \r
- <id>opendaylight-snapshot</id>\r
- <name>opendaylight-snapshot</name>\r
- <url>http://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/</url>\r
- </repository>\r
-</repositories>\r
- \r
-==== Using Plugin\r
-\r
-To add yang-maven-plugin to build section of your pom.xml use:\r
-[literal]\r
-<build>\r
- <plugins>\r
- <plugin>\r
- <groupId>org.opendaylight.yangtools</groupId>\r
- <artifactId>yang-maven-plugin</artifactId>\r
- <version>0.6.1-SNAPSHOT</version>\r
- <!-- configuration -->\r
- </plugin>\r
- </plugins>\r
-</build>\r
+++ /dev/null
-== OpenDaylight Release Notes
-
-=== Key Features
-
-A list of the key functionality provided in OpenDaylight Helium can be found in the table in the <<_installing_components,section below>>.
-
-////
-The following table describes the key features provided by OpenDaylight Helium.
-
-[cols="2",option="headers"]
-|==============================================
-| *Feature* | *Description*
-| Maven support | Used to simplify build automation.
-| OSGi framework | Serves as the controller’s back-end, allowing it to dynamically load bundles, package JAR files, and bind bundles together when exchanging information.
-| Java interface support | Used by specific bundles to implement call-back functions for events and indicate the awareness of specific states.
-| Model- Driven Service Abstraction Layer (MD-SAL) | Allows the controller to support multiple protocols (such as BGP-LS and OpenFlow) on the southbound interface. Also provides consistent services for modules and applications (which is where the business logic is embedded).
-| Switch Manager | Once a network element has been discovered, its details (such as device type, software version, etc.) are stored by the Switch Manager.
-| High Availability (HA) | The controller supports cluster-based HA, allowing you to connect multiple controllers and configure them to act as one in order to ensure the controller’s continuous operation.
-|==============================================
-////
-=== Target Environment
-
-NOTE: If you are using Oracle, JDK version 1.7.0_45 or later is required.
-
-==== For Execution
-
-The OpenDaylight controller source files are completely portable and only require a Java 7-compliant JVM to run.
-
-==== For Development
-
-Although the OpenDaylight controller is developed as a normal Java project, it makes heavy use of the Xtend language in some places. While development is possible with bare tools, we recommend you use Eclipse with the Xtend plugin.
-
-=== Known Issues and Limitation
-
-Other than as noted in project-specific release notes, there are two known limitations.
-
-. The Karaf distribution of OpenDaylight requires internet access when run for the first time.
-. There are scales beyond which the controller has been unreliable when collecting flow statistics from OpenFlow switches. In tests, theses issues became apparent when managing 10s of thousands of OpenFlow switches, however this may vary depending on deployment and use cases. Flow programming has been unaffected in our tests.
-
-==== Full Bug List
-
-All of the known issues for the OpenDaylight controller are listed https://bugs.opendaylight.org/buglist.cgi?bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=WAITING_FOR_REVIEW&columnlist=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate%2Ccf_target_milestone&f1=cf_target_milestone&list_id=15952&n1=1&o1=substring&product=controller&query_based_on=&query_format=advanced&resolution=---&v1=Lithium[here].
-
-=== Project-specific Release Notes
-
-Project-specific release notes can be found on the OpenDaylight wiki. This table provides links to them by project.
-
-[options="header",cols="1,4"]
-|==============================================
-| Project | Release Notes URL
-| AAA | https://wiki.opendaylight.org/view/AAA:Helium_Release_Notes
-| BGPCEP | https://wiki.opendaylight.org/view/BGP_LS_PCEP:Helium_Release_Notes
-| DLUX | https://wiki.opendaylight.org/view/OpenDaylight_dlux:Release_Notes_Helium
-| Group Based Policy | https://wiki.opendaylight.org/view/Group_Policy:Helium-Release-Notes
-| L2 Switch | https://wiki.opendaylight.org/view/L2_Switch:Helium:Release_Notes
-| LISP Flow Mapping | https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:_Helium_Release_Notes
-| OpenFlow Plugin | https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Helium_Release_Notes
-| OpenFlow Protocol Library | https://wiki.opendaylight.org/view/Openflow_Protocol_Library:Release_Notes
-| OVSDB | https://wiki.opendaylight.org/view/OVSDB_Integration:Helium_Release_Notes
-| PackCable PCMM | https://wiki.opendaylight.org/view/PacketCablePCMM:ReleaseNotes
-| Plugin2OC | https://wiki.opendaylight.org/view/Southbound_Plugin_to_the_OpenContrail_Platform:Helium_Release_Notes
-| SDNi | https://wiki.opendaylight.org/view/ODL-SDNi_App:Helium_Release_Notes
-| SNBI | https://wiki.opendaylight.org/view/SecureNetworkBootstrapping:HeliumReleaseNotes
-| SNMP4SDN | https://wiki.opendaylight.org/view/SNMP4SDN:Helium_Release_Note
-| SFC | https://wiki.opendaylight.org/view/Service_Function_Chaining:Helium_Release_Notes
-| TCPMD5 | https://wiki.opendaylight.org/view/TCPMD5:Helium_Release_Notes
-| TTP | https://wiki.opendaylight.org/view/Table_Type_Patterns:Helium_Release_Notes
-| VTN | https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):Helium_Release_Notes
-| Yang Tools | https://wiki.opendaylight.org/view/YANG_Tools:Helium:Release_Notes
-|==============================================
-
+++ /dev/null
-== OpFlex agent-ovs Install Guide
-=== Required Packages
-You'll need to install the following packages and their dependencies:
-
-* libuv
-* openvswitch-gbp
-* openvswitch-gbp-lib
-* openvswitch-gbp-kmod
-* libopflex
-* libmodelgbp
-* agent-ovs
-
-Packages are available for Red Hat Enterprise Linux 7 and Ubuntu 14.04
-LTS. Some of the examples below are specific to RHEL7 but you can run
-the equivalent commands for upstart instead of systemd.
-
-Note that many of these steps may be performed automatically if you're
-deploying this along with a larger orchestration system.
-
-=== Host Networking Configuration
-
-You'll need to set up your VM host uplink interface. You should
-ensure that the MTU of the underlying network is sufficient to handle
-tunneled traffic. We will use an example of setting up *eth0* as your
-uplink interface with a vlan of 4093 used for the networking control
-infrastructure and tunnel data plane.
-
-We just need to set the MTU and disable IPv4 and IPv6
-autoconfiguration. The MTU needs to be large enough to allow both the
-VXLAN header and VLAN tags to pass through without fragmenting for
-best performance. We'll use 1600 bytes which should be sufficient
-assuming you are using a default 1500 byte MTU on your virtual machine
-traffic. If you already have any NetworkManager connections configured
-for your uplink interface find the connection name and proceed to the
-next step. Otherwise, create a connection with (be sure to update the
-variable UPLINK_IFACE as needed):
-
-----
-UPLINK_IFACE=eth0
-nmcli c add type ethernet ifname $UPLINK_IFACE
-----
-
-Now, configure your interface as follows:
-
-----
-CONNECTION_NAME="ethernet-$UPLINK_IFACE"
-nmcli connection mod "$CONNECTION_NAME" connection.autoconnect yes \
- ipv4.method link-local \
- ipv6.method ignore \
- 802-3-ethernet.mtu 9000 \
- ipv4.routes '224.0.0.0/4 0.0.0.0 2000'
-----
-Then bring up the interface with
-
-----
-nmcli connection up "$CONNECTION_NAME"
-----
-
-Next, create the infrastructure interface using the infrastructure
-VLAN (4093 by default). We'll need to create a vlan subinterface of
-your uplink interface, the configure DHCP on that interface. Run the
-following commands. Be sure to replace the variable values if needed. If
-you're not using NIC teaming, replace the variable team0 below
-
-----
-UPLINK_IFACE=team0
-INFRA_VLAN=4093
-nmcli connection add type vlan ifname $UPLINK_IFACE.$INFRA_VLAN dev $UPLINK_IFACE id $INFRA_VLAN
-nmcli connection mod vlan-$UPLINK_IFACE.$INFRA_VLAN \
- ethernet.mtu 1600 ipv4.routes '224.0.0.0/4 0.0.0.0 1000'
-sed "s/CLIENT_ID/01:$(ip link show $UPLINK_IFACE | awk '/ether/ {print $2}')/" \
- > /etc/dhcp/dhclient-$UPLINK_IFACE.$INFRA_VLAN.conf <<EOF
-send dhcp-client-identifier CLIENT_ID;
-request subnet-mask, domain-name, domain-name-servers, host-name;
-EOF
-----
-Now bring up the new interface with:
-
-----
-nmcli connection up vlan-$UPLINK_IFACE.$INFRA_VLAN
-----
-If you were successful, you should be able to see an IP address when you run:
-
-----
-ip addr show dev $UPLINK_IFACE.$INFRA_VLAN
-----
-
-=== OVS Bridge Configuration
-We'll need to configure an OVS bridge which will handle the traffic
-for any virtual machines or containers that are hosted on the VM
-host. First, enable the openvswitch service and start it:
-
-----
-# systemctl enable openvswitch
-ln -s '/usr/lib/systemd/system/openvswitch.service' '/etc/systemd/system/multi-user.target.wants/openvswitch.service'
-# systemctl start openvswitch
-# systemctl status openvswitch
-openvswitch.service - Open vSwitch
- Loaded: loaded (/usr/lib/systemd/system/openvswitch.service; enabled)
- Active: active (exited) since Fri 2014-12-12 17:20:13 PST; 3s ago
- Process: 3053 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
- Main PID: 3053 (code=exited, status=0/SUCCESS)
-Dec 12 17:20:13 ovs-server.cisco.com systemd[1]: Started Open vSwitch.
-----
-
-Next, we can create an OVS bridge (you may wish to use a different
-bridge name):
-
-----
-# ovs-vsctl add-br br0
-# ovs-vsctl show
-34aa83d7-b918-4e49-bcec-1b521acd1962
- Bridge "br0"
- Port "br0"
- Interface "br0"
- type: internal
- ovs_version: "2.3.90"
-----
-
-Next, we configure a tunnel interface on our new bridge as follows:
-
-----
-# ovs-vsctl add-port br0 br0_vxlan0 -- \
- set Interface br0_vxlan0 type=vxlan \
- options:remote_ip=flow options:key=flow options:dst_port=8472
-# ovs-vsctl show
-34aa83d7-b918-4e49-bcec-1b521acd1962
- Bridge "br0"
- Port "br0_vxlan0"
- Interface "br0_vxlan0"
- type: vxlan
- options: {dst_port="8472", key=flow, remote_ip=flow}
- Port "br0"
- Interface "br0"
- type: internal
- ovs_version: "2.3.90"
-----
-
-Open vSwitch is now configured and ready.
-
-=== Agent Configuration
-Before enabling the agent, we'll need to edit its configuration file,
-which is located at "/etc/opflex-agent-ovs/opflex-agent-ovs.conf".
-
-First, we'll configure the Opflex protocol parameters. If you're using
-an ACI fabric, you'll need the OpFlex domain from the ACI
-configuration, which is the name of the VMM domain you mapped to the
-interface for this hypervisor. Set the "domain" field to this
-value. Next, set the "name" field to a hostname or other unique
-identifier for the VM host. Finally, set the "peers" list to contain
-the fixed static anycast peer address of 10.0.0.30 and port 8009. Here
-is an example of a completed section (bold text shows areas you'll
-need to modify):
-
-----
-"opflex": {
- // The globally unique policy domain for this agent.
- "domain": "[CHANGE ME]",
-
- // The unique name in the policy domain for this agent.
- "name": "[CHANGE ME]",
-
- // a list of peers to connect to, by hostname and port. One
- // peer, or an anycast pseudo-peer, is sufficient to bootstrap
- // the connection without needing an exhaustive list of all
- // peers.
- "peers": [
- {"hostname": "10.0.0.30", "port": 8009}
- ],
-
- "ssl": {
- // SSL mode. Possible values:
- // disabled: communicate without encryption
- // encrypted: encrypt but do not verify peers
- // secure: encrypt and verify peer certificates
- "mode": "encrypted",
-
- // The path to a directory containing trusted certificate
- // authority public certificates, or a file containing a
- // specific CA certificate.
- "ca-store": "/etc/ssl/certs/"
- }
-},
-----
-
-Next, configure the appropriate policy renderer for the ACI
-fabric. You'll want to use a stitched-mode renderer. You'll need to
-configure the bridge name and the uplink interface name. The remote
-anycast IP address will need to be obtained from the ACI configuration
-console, but unless the configuration is unusual, it will be
-10.0.0.32.
-
-----
-// Renderers enforce policy obtained via OpFlex.
-"renderers": {
- // Stitched-mode renderer for interoperating with a
- // hardware fabric such as ACI
- "stitched-mode": {
- "ovs-bridge-name": "br0",
-
- // Set encapsulation type. Must set either vxlan or vlan.
- "encap": {
- // Encapsulate traffic with VXLAN.
- "vxlan" : {
- // The name of the tunnel interface in OVS
- "encap-iface": "br0_vxlan0",
-
- // The name of the interface whose IP should be used
- // as the source IP in encapsulated traffic.
- "uplink-iface": "eth0.4093",
-
- // The vlan tag, if any, used on the uplink interface.
- // Set to zero or omit if the uplink is untagged.
- "uplink-vlan": 4093,
-
- // The IP address used for the destination IP in
- // the encapsulated traffic. This should be an
- // anycast IP address understood by the upstream
- // stitched-mode fabric.
- "remote-ip": "10.0.0.32"
- }
- },
- // Configure forwarding policy
- "forwarding": {
- // Configure the virtual distributed router
- "virtual-router": {
- // Enable virtual distributed router. Set to true
- // to enable or false to disable. Default true.
- "enabled": true,
-
- // Override MAC address for virtual router.
- // Default is "00:22:bd:f8:19:ff"
- "mac": "00:22:bd:f8:19:ff",
-
- // Configure IPv6-related settings for the virtual
- // router
- "ipv6" : {
- // Send router advertisement messages in
- // response to router solicitation requests as
- // well as unsolicited advertisements.
- "router-advertisement": true
- }
- },
-
- // Configure virtual distributed DHCP server
- "virtual-dhcp": {
- // Enable virtual distributed DHCP server. Set to
- // true to enable or false to disable. Default
- // true.
- "enabled": true,
-
- // Override MAC address for virtual dhcp server.
- // Default is "00:22:bd:f8:19:ff"
- "mac": "00:22:bd:f8:19:ff"
- }
- },
-
- // Location to store cached IDs for managing flow state
- "flowid-cache-dir": "DEFAULT_FLOWID_CACHE_DIR"
- }
-}
-----
-
-Finally, enable the agent service:
-
-----
-# systemctl enable agent-ovs
-ln -s '/usr/lib/systemd/system/agent-ovs.service' '/etc/systemd/system/multi-user.target.wants/agent-ovs.service'
-# systemctl start agent-ovs
-# systemctl status agent-ovs
-agent-ovs.service - Opflex OVS Agent
- Loaded: loaded (/usr/lib/systemd/system/agent-ovs.service; enabled)
- Active: active (running) since Mon 2014-12-15 10:03:42 PST; 5min ago
- Main PID: 6062 (agent_ovs)
- CGroup: /system.slice/agent-ovs.service
- └─6062 /usr/bin/agent_ovs
-----
-
-The agent is now running and ready to enforce policy. You can add
-endpoints to the local VM hosts using the OpFlex Group-based policy
-plugin from OpenStack, or manually.
+++ /dev/null
-== OVSDB NetVirt Hardware VTEP Installation Guide
-
-=== Overview
-
-TBD
-
-=== Preparing for Installation
-Follow the instructions in <<_getting_and_installing_opendaylight,Getting and Installing OpenDaylight>>.
-
-=== Installing OVSDB NetVirt Hardware VTEP
-Install the required features with the following command:
------
-feature:install odl-ovsdb-netvirt-hwvtep
------
-
-==== Sample output from the Karaf console
-----
-TBD
-----
-
-=== Verifying your Installation
-To verify that the installation was successful, use the following command in karaf and check that there
-are no error logs relating to odl-ovsdb-netvirt-hwvtep
------
-log:display
------
-
-==== Troubleshooting
-
-TBD
-
-=== Uninstalling OVSDB NetVirt Hardware VTEP
-. Shutdown the karaf instance:
-+
------
-system:shutdown
------
-. Remove what is in the /data folder of the OpenDaylight Distribution.
+++ /dev/null
-
-include::ovsdb-openstack-install.adoc[]
-
-include::ovsdb-sfc-install.adoc[]
-
-include::ovsdb-hwvtep-install.adoc[]
-
+++ /dev/null
-== OVSDB OpenStack Installation Guide
-
-=== Overview
-This guide is geared towards installing OpenDaylight to use the OVSDB project to provide Neutron support for OpenStack.
-
-Open vSwitch (OVS) is generally accepted as the unofficial standard for Virtual Switching in the Open hypervisor based solutions.
-For information on OVS, see http://openvswitch.org/[Open vSwitch].
-
-With OpenStack within the SDN context, controllers and applications interact using two channels: OpenFlow and OVSDB. OpenFlow addresses the forwarding-side of the OVS functionality. OVSDB, on the other hand, addresses the management-plane.
-A simple and concise overview of Open Virtual Switch Database (OVSDB) is available at: http://networkstatic.net/getting-started-ovsdb/
-
-=== Preparing for Installation
-Follow the instructions in <<_getting_and_installing_opendaylight,Getting and Installing OpenDaylight>>.
-
-=== Installing OVSDB OpenStack
-Install the required features with the following command:
------
-feature:install odl-ovsdb-openstack
------
-
-==== Sample output from the Karaf console
-----
-opendaylight-user@root>feature:list -i | grep ovsdb
-odl-ovsdb-southbound-api | 1.1.0-SNAPSHOT | x | odl-ovsdb-southbound-1.1.0-SNAPSHOT
-OpenDaylight :: southbound :: api
-odl-ovsdb-southbound-impl | 1.1.0-SNAPSHOT | x | odl-ovsdb-southbound-1.1.0-SNAPSHOT
-OpenDaylight :: southbound :: impl
-odl-ovsdb-southbound-impl-rest | 1.1.0-SNAPSHOT | x | odl-ovsdb-southbound-1.1.0-SNAPSHOT
-OpenDaylight :: southbound :: impl :: REST
-odl-ovsdb-southbound-impl-ui | 1.1.0-SNAPSHOT | x | odl-ovsdb-southbound-1.1.0-SNAPSHOT
-OpenDaylight :: southbound :: impl :: UI
-odl-ovsdb-openstack | 1.1.0-SNAPSHOT | x | ovsdb-1.1.0-SNAPSHOT
-OpenDaylight :: OVSDB :: OpenStack Network Virtual
-----
-
-=== Verifying your Installation
-To verify that the installation was successful, use the following command in karaf and check that there are no errors
-logs relating to odl-ovsdb-openstack.
------
-log:display
------
-
-==== Troubleshooting
-There is no easy way to troubleshoot an installation of odl-ovsdb-openstack. Perhaps a combination of
-log:display | grep -i ovsdb in karaf, Open vSwitch commands (ovs-vsctl) and OpenStack logs will be useful but will not
-explain everything.
-
-=== Uninstalling OVSDB OpenStack
-. Shutdown the karaf instance:
-+
------
-system:shutdown
------
-. Remove what is in the /data folder of the OpenDaylight Distribution.
+++ /dev/null
-== OVSDB Service Function Chaining Installation Guide
-
-=== Overview
-
-TBD
-
-=== Preparing for Installation
-Follow the instructions in <<_getting_and_installing_opendaylight,Getting and Installing OpenDaylight>>.
-
-=== Installing OVSDB Service Function Chaining
-Install the required features with the following command:
------
-feature:install odl-ovsdb-sfc-ui
------
-
-==== Sample output from the Karaf console
-----
-TBD
-----
-
-=== Verifying your Installation
-To verify that the installation was successful, use the following command in karaf and check that there are
-no error logs relating to odl-ovsdb-sfc
------
-log:display
------
-==== Troubleshooting
-
-TBD
-
-=== Uninstalling OVSDB Service Function Chaining
-. Shutdown the karaf instance:
-+
------
-system:shutdown
------
-. Remove what is in the /data folder of the OpenDaylight Distribution.
+++ /dev/null
-== OpenDaylight Release Notes
-
-// NOTE: If you are editing this file, please try to keep it in sync
-// with the wiki here:
-// https://wiki.opendaylight.org/view/Simultaneous_Release/Beryllium/Release_Notes
-
-=== Target Environment
-
-==== For Execution
-
-The OpenDaylight Karaf container, OSGi bundles, and Java class files
-are portable and should run on any Java 7- or Java 8-compliant JVM to
-run. Certain projects and certain features of some projects may have
-additional requirements. Those are noted in the project-specific
-release notes.
-
-Projects and features which have known additional requirements are:
-* TCP-MD5 requires 64-bit Linux
-* TSDR has extended requirements for external databases
-* Persistence has extended requirements for external databases
-* SFC requires addition features for certain configurations
-* SXP depends on TCP-MD5 on thus requires 64-bit Linux
-* SNBI has requirements for Linux and Docker
-* OpFlex requires Linux
-* DLUX requires a modern web browser to view the UI
-* AAA when using federation has additional requirements for external tools
-* VTN has components which require Linux
-
-NOTE: If you are using the Oracle JDK, version 1.7.0_45 or later is required.
-
-==== For Development
-
-OpenDaylight is written primarily in Java project and primarily uses
-Maven as a build tool Consequently the two main requirements to develop
-projects within OpenDaylight are:
-
-* A Java 7- or Java 8-compliant JDK
-* Maven 3.1.1 or later
-
-Applications and tools built on top of OpenDaylight using it's REST
-APIs should have no special requirements beyond whatever is needed to
-run the application or tool and make the REST calls.
-
-In some places, OpenDaylight makes use of the Xtend language. While
-Maven will download the appropriate tools to build this, additional
-plugins may be required for IDE support.
-
-The projects with additional requirements for execution typically have
-similar or more extensive additional requirements for development. See
-the project-specific release notes for details.
-
-=== Known Issues and Limitations
-
-Other than as noted in project-specific release notes, we know of the
-following limitations:
-
-. Migration from Helium and Lithium to Beryllium has not been
-extensively tested. The per-project release notes include migration and
-compatibility information when it is known.
-. There are scales beyond which the controller has been unreliable when
-collecting flow statistics from OpenFlow switches. In tests, these
-issues became apparent when managing thousands of OpenFlow
-switches, however this may vary depending on deployment and use cases.
-
-=== Project-specific Release Notes
-
-For the release notes of individual projects, please see the following pages on the OpenDaylight Wiki.
-
-TBD: add Beryllium release notes
-
-==== Projects without Release Notes
-
-The following projects participated in Beryllium, but intentionally do not have release notes.
-
-* *Documentation Project* produced this and the other downloadable documentation
-* *Integration Group* hosted the OpenDaylight-wide tests and main release distribution
-* *Release Engineering - autorelease* was used to build the Beryllium release artifacts and including the main release download.
+++ /dev/null
-== TSDR Installation Guide
-This document is for the user to install the artifacts that are needed
-for using Time Series Data Repository (TSDR) functionality in the ODL
-Controller by enabling either an HSQLDB, HBase, or Cassandra Data Store.
-
-
-=== Overview
-The Time Series Data Repository (TSDR) project in OpenDaylight (ODL) creates a framework for collecting, storing, querying, and maintaining time series data in the OpenDaylight SDN controller. Please refer to the User Guide for the detailed description of the functionality of the project and how to use the corresponding features provided in TSDR.
-
-=== Pre Requisites for Installing TSDR
-The software requirements for TSDR HBase Data Store are as follows:
-
-* In the case when the user chooses HBase or Cassandra data store, besides the software that ODL requires, we also require HBase and Cassandra database running in single node deployment scenario.
-
-No additional software is required for the HSQLDB Data Stores.
-
-=== Preparing for Installation
-* When using HBase data store, download HBase from the following website:
-
- http://archive.apache.org/dist/hbase/hbase-0.94.15/
-
-* When using Cassandra data store, download Cassandra from the following website:
-
- http://www.eu.apache.org/dist/cassandra/2.1.10/
-
-* No additional steps are required to install the TSDR HSQL Data Store.
-
-=== Installing TSDR Data Stores
-==== Installing HSQLDB Data Store
-Once OpenDaylight distribution is up, from karaf console install the HSQLDB data store using the following command:
-
- feature:install odl-tsdr-hsqldb-all
-
-This will install hsqldb related dependency features (and can take sometime) as well as openflow statistics collector before returning control to the console.
-e
-
-==== Installing HBase Data Store
-Installing TSDR HBase Data Store contains two steps:
-
- * Installing HBase server, and
- * Installing TSDR HBase Data Store features from ODL Karaf console.
-
-In Beryllium, we only support HBase single node running together on the same machine as OpenDaylight. Therefore, follow the steps to download and install HBase server onto the same machine as where OpenDaylight is running:
-
-* Create a folder in Linux operating system for the HBase server.
-
-For example, create an hbase directory under /usr/lib:
-
- mkdir /usr/lib/hbase
-
-* Unzip the downloaded HBase server tar file.
-
-Run the following command to unzip the installation package:
-
- tar xvf <hbase-installer-name> /usr/lib/hbase
-
-* Make proper changes in hbase-site.xml
-
- .. Under <hbase-install-directory>/conf/, there is a hbase-site.xml. Although it is not recommended, an experienced user with HBase can modify the data directory for hbase server to store the data.
-
- .. Modify the value of the property with name "hbase.rootdir" in the file to reflect the desired file directory for storing hbase data.
-
-The following is an example of the file:
-
- <configuration>
- <property>
- <name>hbase.rootdir</name>
- <value>file:///usr/lib/hbase/data</value>
- </property>
- <property>
- <name>hbase.zookeeper.property.dataDir</name>
- <value>/usr/lib/hbase/zookeeper</value>
- </property>
- </configuration>
-
-* start hbase server
-
- cd <hbase-installation-directory>
- ./start-hbase.sh
-
-* start hbase shell
-
- cd <hbase-insatllation-directory>
- ./hbase shell
-
-* start Karaf console
-
-* install hbase data store feature from Karaf console
-
- feature:install odl-tsdr-hbase
-
-==== Installing Cassandra Data Store
-Installing TSDR Cassandra Data Store contains two steps:
-
- * Installing Cassandra server, and
- * Installing TSDR Cassandra Data Store features from ODL Karaf console.
-
-In Beryllium, we only support Cassadra single node running together on the same machine as OpenDaylight. Therefore, follow these steps to download and install Cassandra server onto the same machine as where OpenDaylight is running:
-
-Install Cassandra (latest stable version) by downloading the zip file and untar the tar ball to cassandra/ directory on the testing machine.
-
- mkdir cassandra
- wget http://www.eu.apache.org/dist/cassandra/2.1.10/apache-cassandra-2.1.10-bin.tar.gz[2.1.10 is current stable version, it can vary]
- mv apache-cassandra-2.1.10-bin.tar.gz cassandra/
- cd cassandra
- tar -xvzf apache-cassandra-2.1.10-bin.tar.gz
-
-Start Cassandra from cassandra directory by running:
-
- ./apache-cassandra-2.1.10/bin/cassandra
-
-Start cassandra shell by running:
-
- ./apache-cassandra-2.1.10/bin/cqlsh
-
-Start Karaf according to the instructions above.
-
-Install Cassandra data store feature from Karaf console:
-
- feature:install odl-tsdr-cassandra
-
-=== Verifying your Installation
-
-After the TSDR data store is installed, no matter whether it is HBase data store, Cassandra data store, or HSQLDB data store, the user can verify the installation with the following steps.
-
-* Verify if the following two tsdr commands are available from Karaf console:
-
-** tsdr:list
-** tsdr:purgeAll
-
-* Verify if openflow statisitcs data can be received successfully:
-
-** Run "feature:install odl-tsdr-openflow-statistics-collector" from Karaf.
-
-** Run mininet to connect to ODL controller. For example, use the following command to start a three node topology:
-
- "mn --topo single,3 --controller 'remote,ip=172.17.252.210,port=6653' --switch ovsk,protocols=OpenFlow13"
-
-** From Karaf console, the user should be able to retrieve the statistics data of OpenFlow statistics data from the console:
-
- tsdr:list FLOWSTATS
-
-==== Troubleshooting
-Check the ../data/log/karaf.log for any exception related to TSDR features.
-
-==== Post Installation Configuration
-===== Post Installation Configuration for HSQLDB Data Store
-
-The feature installation takes care of automated configuration of the datasource by installing a file in <install folder>/etc named org.ops4j.datasource-metric.cfg. This contains the default location of <install folder>/tsdr where the HSQLDB datastore files are stored. If you want to change the default location of the datastore files to some other location update the last portion of the url property in the org.ops4j.datasource-metric.cfg and then restart the Karaf container.
-
-===== Post Installation Configuration for HBase Data Store
-
-Please refer to HBase Data Store User Guide.
-
-===== Post Installation Configuration for Cassandra Data Store
-
-There is no post configuration for TSDR Cassandra data store.
-
-=== Upgrading From a Previous Release
-The HBase data store was supported in the previous release as well as in this release. However, we do not support data store upgrade for HBase data store.
-The user needs to reinstall TSDR and start to collect data in TSDR HBase datastore after the installation.
-
-HSQLDB and Cassandra are new data stores introduced in this release. Therefore, upgrading from previous release does not apply in these two data store scenarios.
-
-=== Uninstalling TSDR Data Stores
-==== To uninstall TSDR HSQLDB data store
-To uninstall the TSDR functionality with the default store, you need to do the following from karaf console
-
- feature:uninstall odl-tsdr-hsqldb-all
- feature:uninstall odl-tsdr-core
- feature:uninstall odl-tsdr-hsqldb
- feature:uninstall odl-tsdr-openflow-statistics-collector
-
-It is recommended to restart the Karaf container after the uninstallation of the TSDR functionality with the default store.
-
-==== To uninstall TSDR HBase Data Store
-To uninstall the TSDR functionality with the HBase data store,
-
-* Uninstall HBase data store related features from karaf console
-
- feature:uninstall odl-tsdr-hbase
- feature:uninstall odl-tsdr-core
-
-* stop hbase server
-
- cd <hbase-installation-directory>
- ./stop-hbase.sh
-
-* remove the file directory that contains the HBase server installation
-
- rm -r <hbase-installation-directory>
-
-It is recommended to restart the Karaf container after the uninstallation of the TSDR data store.
-==== To uninstall TSDR Cassandra Data Store
-To uninstall the TSDR functionality with the Cassandra store,
-
-* uninstall cassandra data store related features following from karaf console
-
- feature:uninstall odl-tsdr-cassandra
- feature:uninstall odl-tsdr-core
-
-* stop cassandra database
-
- ps auwx | grep cassandra
- sudo kill pid
-
-* remove the cassandra installation files
-
- rm <cassandra-installation-directory>
-
-It is recommended to restart the Karaf container after uninstallation of the TSDR data store.
</properties>
<modules>
<module>readme</module> <!-- this is just to make sure readme builds -->
- <module>getting-started-guide</module>
<module>developer-guide</module>
<module>user-guide</module>
<module>howto-openstack</module>
include::ch-introduction.adoc[OpenDaylight Controller Overview]
-//TODO: these three includes are a hugely ugly hack that needs to go
-include::../../../../getting-started-guide/src/main/asciidoc/ch-dlux.adoc[]
+include::ch-dlux.adoc[]
-include::../../../../getting-started-guide/src/main/asciidoc/ch-xsql-commands.adoc[]
+include::ch-xsql-commands.adoc[]
-include::../../../../getting-started-guide/src/main/asciidoc/ch-clustering.adoc[]
+include::ch-clustering.adoc[]
= Applications and Plugins
include::nic/nic-user.adoc[NIC]
+include::ocpplugin/ocp-user-guide.adoc[OCP]
+
include::sdninterfaceapp/odl-sdninterfaceapp-all-user.adoc[ODL-SDNi]
include::openflowplugin/odl-ofp-user-guide.adoc[OpenFlow Plugin]
include::controller/netconf/odl-netconf-user.adoc[]
+include::yangide/yangide-user.adoc[]
+
include::yang-push/odl-yang-push-user.adoc[YANG-PUSH]
support the APIs defined by the RPCs. There may be different Driver
implementations for different device types.
-//=== Configuring DIDM
-//TODO
-//
-//=== Administering or Managing DIDM
-//TODO
+=== Installing DIDM
+
+To install DIDM, download OpenDaylight and use the Karaf console to install the following features:
+
+* odl-openflowplugin-all
+* odl-didm-all
+
+odl-didm-all installs the following required features:
+
+* odl-didm-ovs-all
+* odl-didm-ovs-impl
+* odl-didm-util
+* odl-didm-identification
+* odl-didm-drivers
+* odl-didm-hp-all
+
+=== Configuring DIDM
+
+This section shows an example configuration steps for installing a driver (HP 3800 OpenFlow switch driver).
+
+=== Install DIDM features:
+
+----
+feature:install odl-didm-identification-api
+feature:install odl-didm-drivers
+----
+
+In order to identify the device, device driver needs to be installed first.
+Identification Manager will be notified when a new device connects to the controller.
+
+=== Install HP driver
+
+feature:install odl-didm-hp-all installs the following features
+
+* odl-didm-util
+* odl-didm-identification
+* odl-didm-drivers
+* odl-didm-hp-all
+* odl-didm-hp-impl
+
+Now at this point, the driver has written all of the identification information in to the MD-SAL datastore.
+The identification manager should have that information so that it can try to identify the HP 3800 device when it connects to the controller.
+
+Configure the switch and connect it to the controller from the switch CLI.
+
+=== Run REST GET command to verify the device details:
+
+http://<CONTROLLER-IP:8181>/restconf/operational/opendaylight-inventory:nodes
+
+=== Run REST adjust-flow command to adjust flows and push to the device
+
+.Flow mod driver for HP 3800 device is added in Beryllium release
+This driver adjusts the flows and push the same to the device.
+This API takes the flow to be adjusted as input and displays the adjusted flow as output in the REST output container.
+Here is the REST API to adjust and push flows to HP 3800 device:
+
+http://<CONTROLLER-IP:8181>/restconf/operations/openflow-feature:adjust-flow
--- /dev/null
+== OCP Plugin User Guide
+This document describes how to use the ORI Control & Management Protocol (OCP)
+feature in OpenDaylight. This document contains overview, scope, architecture and
+design, installation, configuration and tutorial sections for the feature.
+
+=== Overview
+OCP is an ETSI standard protocol for control and management of Remote Radio Head (RRH)
+equipment. The OCP Project addresses the need for a southbound plugin that allows
+applications and controller services to interact with RRHs using OCP. The OCP southbound
+plugin will allow applications acting as a Radio Equipment Control (REC) to interact
+with RRHs that support an OCP agent.
+
+.OCP southbound plugin
+image::ocpplugin/ocp-sb-plugin.jpg[OCP southbound plugin, 550, 350]
+
+It is foreseen that, in 5G, C-RAN will use the packet-based Transport-SDN (T-SDN) as the
+fronthaul network to transport both control plane and user plane data between RRHs and
+BBUs. As a result, the addition of the OCP plugin to the ODL controller will make it
+possible to build an RRH controller on top of ODL to centrally manage deployed RRHs,
+as well as integrating the RRH controller with T-SDN on one single platform, achieving
+the joint RRH and fronthaul network provisioning in C-RAN.
+
+=== Scope
+The OCP Plugin project includes:
+
+* OCP v4.1.1 support
+* Integration of OCP protocol library
+* Simple API invoked as a RPC
+* Simple API that allows applications to perform elementary functions of the following categories:
+ - Device management
+ - Config management
+ - Object lifecycle
+ - Object state management
+ - Fault management
+ - Software management (not implemented as of Boron)
+* Indication processing
+* Logging (not implemented as of Boron)
+* AISG/Iuant interface message tunnelling (not implemented as of Boron)
+* ALD connection management (not implemented as of Boron)
+
+=== Architecture and Design
+OCP is a vendor-neutral standard communications interface defined to enable control and management
+between RE and REC of an ORI architecture. The OCP Plugin supports the implementation of the OCP
+specification; it is based on the Model Driven Service Abstraction Layer (MD-SAL) architecture.
+
+OCP Plugin will support the following functionality:
+
+* Connection handling
+* Session management
+* State management
+* Error handling
+* Connection establishment will be handled by OCP library using opensource netty.io library
+* Message handling
+* Event/indication handling and propagation to upper layers
+
+*Activities in OCP plugin module*
+
+* Integration with OCP protocol library
+* Integration with corresponding MD-SAL infrastructure
+
+OCP protocol library is a component in OpenDaylight that mediates communication between
+OpenDaylight controller and RRHs supporting OCP protocol. Its primary goal is to provide
+the OCP Plugin with communication channel that can be used for managing RRHs.
+
+Key objectives:
+
+* Immutable transfer objects generation (transformation of OCP protocol library's POJO
+objects into OpenDaylight DTO objects)
+* Scalable non-blocking implementation
+* Pipeline processing
+* Scatter buffer
+* TLS support
+
+OCP Service addresses the need for a northbound interface that allows applications and other
+controller services to interact with RRHs using OCP, by providing API for abstracting OCP operations.
+
+.Overall architecture
+image::ocpplugin/plugin-design.jpg[Overall architecture, 550, 284]
+
+=== Message Flow
+.Message flow example
+image::ocpplugin/message_flow.jpg[Message flow example, 550, 335]
+
+=== Installation
+The OCP Plugin project has two top level Karaf features, odl-ocpplugin-all and odl-ocpjava-all, which contain the following sub-features:
+
+* odl-ocpplugin-southbound
+* odl-ocpplugin-app-ocp-service
+* odl-ocpjava-protocol
+
+The OCP service (odl-ocpplugin-app-ocp-service), together with the OCP southbound (odl-ocpplugin-southbound) and OCP protocol library (odl-ocpjava-protocol), provides the ODL controller with basic OCP v4.1.1 functionality.
+
+There are two ways to interact with OCP service: one is via RESTCONF (programmatic) and the other is using DLUX web interface (manual), so you have to install the following features to enable RESTCONF and DLUX.
+----
+karaf#>feature:install odl-restconf odl-l2switch-switch odl-mdsal-apidocs odl-dlux-core odl-dlux-all
+----
+Then install the odl-ocpplugin-all feature which includes the odl-ocpplugin-southbound and odl-ocpplugin-app-ocp-service features. Note that the odl-ocpjava-all feature will be installed automatically as the odl-ocpplugin-southbound feature is dependent on the odl-ocpjava-protocol feature.
+----
+karaf#>feature:install odl-ocpplugin-all
+----
+After all required features are installed, use following command from karaf console to check and make sure features are correctly installed and initialized.
+----
+karaf#>feature:list | grep ocp
+----
+
+=== Configuration
+Configuring the OCP plugin can be done via its configuration file, 62-ocpplugin.xml, which can be found in the <odl-install-dir>/etc/opendaylight/karaf/ directory.
+
+As of Boron, there are the following settings that are configurable:
+
+. **port** specifies the port number on which the OCP plugin listens for connection requests
+. **radioHead-idle-timeout** determines the time duration (unit: milliseconds) for which a radio head has been idle before the idle event is triggered to perform health check
+. **ocp-version** specifies the OCP protocol version supported by the OCP plugin
+. **rpc-requests-quota** sets the maximum number of concurrent rpc requests allowed
+. **global-notification-quota** sets the maximum number of concurrent notifications allowed
+
+.OCP plugin configuration
+image::ocpplugin/plugin-config.jpg[OCP plugin configuration, 550, 449]
+
+=== Test Environment
+The OCP Plugin project contains a simple OCP agent for testing purposes; the agent has been designed specifically to act as a fake radio head device, giving you an idea of what it would look like during the OCP handshake taking place between the OCP agent and the ODL controller (OCP plugin).
+
+To run the simple OCP agent, you have to first compile it (assuming you have JDK 1.7 or above installed already):
+----
+cd <ocpplugin-src-dir>/simple-agent
+javac src/main/java/org/opendaylight/ocpplugin/OcpAgent.java
+----
+Then run the agent with no arguments and it should display the usage that lists the expected arguments.
+----
+java -cp src/main/java org.opendaylight.ocpplugin.OcpAgent
+
+Usage: java org.opendaylight.ocpplugin.OcpAgent <controller's ip address> <port number> <vendor id> <serial number>
+----
+Here is an example:
+----
+java -cp src/main/java org.opendaylight.ocpplugin.OcpAgent 127.0.0.1 1033 XYZ 123
+----
+
+=== Web / Graphical Interface
+Once you enable the DLUX feature, you can access the Controller GUI using following URL.
+----
+http://<controller-ip>:8080/index.html
+----
+Expand Nodes. You should see all the radio head devices that are connected to the controller running at <controller-ip>.
+
+.DLUX Nodes
+image::ocpplugin/dlux-ocp-nodes.jpg[DLUX Nodes, 550, 312]
+
+And expand Yang UI if you want to browse the various northbound APIs exposed by the OCP service.
+
+.DLUX Yang UI
+image::ocpplugin/dlux-ocp-apis.jpg[DLUX Yang UI, 550, 468]
+
+For information on how to use these northbound APIs, please refer to the OCP Plugin Developer Guide.
+
+=== Programmatic Interface
+The OCP Plugin project has implemented a complete set of the C&M operations (elementary functions) defined
+in the OCP specification, in the form of both northbound and southbound APIs, including:
+
+* health-check
+* set-time
+* re-reset
+* get-param
+* modify-param
+* create-obj
+* delete-obj
+* get-state
+* modify-state
+* get-fault
+
+The API is documented in the OCP Plugin Developer Guide under the section Southbound API and Northbound API, respectively.
** Cassandra log
*** Cassandra log is under {cassandra.logdir}/system.log. The default {cassandra.logdir} is /var/log/cassandra/.
+=== Security
+TSDR gets the data from a variety of sources, which can be secured in different ways.
+
+** OpenFlow Security
+*** The OpenFlow data can be configured with Transport Layer Security (TLS) since the OpenFlow Plugin that TSDR depends on provides this security support.
+
+** SNMP Security
+*** The SNMP version3 has security support. However, since ODL SNMP Plugin that TSDR depends on does not support version 3, we (TSDR) will not have security support at this moment.
+
+** NetFlow Security
+*** NetFlow, which cannot be configured with security so we recommend making sure it flows only over a secured management network.
+
+** Syslog Security
+*** Syslog, which cannot be configured with security so we recommend making sure it flows only over a secured management network.
|===
.Flow Filter Example
-image::vtn/Flow_filter_example.png["Flow filter example",width=500]
+image::vtn/flow_filter_example.png["Flow filter example",width=500]
* Following steps explain flow-filter function:
--- /dev/null
+== YangIDE User Guide
+Refer to this template to identify the required sections and information
+that you should provide for a User Guide. The user guide should contain
+configuration, administration, management, using, and troubleshooting
+sections for the feature.
+
+=== Overview
+Provide an overview of the feature and the use case. Also include the
+audience who will use the feature. For example, audience can be the
+network administrator, cloud administrator, network engineer, system
+administrators, and so on.
+
+=== YangIDE Architecture
+Provide information about feature components and how they work together.
+Also include information about how the feature integrates with
+OpenDaylight. An architecture diagram could help.
+
+=== Configuring YangIDE
+
+Describe how to configure the feature or the project after installation.
+Configuration information could include day-one activities for a project
+such as configuring users, configuring clients/servers and so on.
+
+=== Administering or Managing YangIDE
+Include related command reference or operations that you could perform
+using the feature. For example viewing network statistics, monitoring
+the network, generating reports, and so on.
+
+NOTE: Ensure that you create a step procedure whenever required and
+avoid concepts.
+
+For example:
+
+.To configure L2switch components perform the following steps.
+. Step 1:
+. Step 2:
+. Step 3:
+
+=== Tutorials
+<optional>
+If there is only one tutorial, you skip the "Tutorials" section and
+instead just lead with the single tutorial's name.
+
+==== <Tutorial Name>
+Ensure that the title starts with a gerund. For example using,
+monitoring, creating, and so on.
+
+===== Overview
+An overview of the use case.
+
+===== Prerequisites
+Provide any prerequisite information, assumed knowledge, or environment
+required to execute the use case.
+
+===== Target Environment
+Include any topology requirement for the use case. Ideally, provide
+visual (abstract) layout of network diagrams and any other useful visual
+aides.
+
+===== Instructions
+Use case could be a set of configuration procedures. Including
+screenshots to help demonstrate what is happening is especially useful.
+Ensure that you specify them separately. For example:
+
+. *Setting up the VM*
+To set up a VM perform the following steps.
+.. Step 1
+.. Step 2
+.. Step 3
+
+. *Installing the feature*
+To install the feature perform the following steps.
+.. Step 1
+.. Step 2
+.. Step 3
+
+. *Configuring the environment*
+To configure the system perform the following steps.
+.. Step 1
+.. Step 2
+.. Step 3
<version>0.1.0</version>
</plugin>
<plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-site-plugin</artifactId>
- <version>3.1</version>
- <dependencies>
- <dependency>
- <groupId>org.apache.maven.wagon</groupId>
-
<artifactId>wagon-webdav-jackrabbit</artifactId>
- <version>2.2</version>
- </dependency>
- <dependency>
- <groupId>org.slf4j</groupId>
-
<artifactId>slf4j-api</artifactId>
- <version>1.6.1</version>
- </dependency>
- </dependencies>
- </plugin>
- </plugins>
+ <groupId>org.apache.maven.plugins</groupId>
+
<artifactId>maven-site-plugin</artifactId>
+ <version>3.1</version>
+ <dependencies>
+ <dependency>
+ <groupId>org.apache.maven.wagon</groupId>
+ <artifactId>wagon-webdav-jackrabbit</artifactId>
+ <version>2.2</version>
+ </dependency>
+ <dependency>
+ <groupId>org.slf4j</groupId>
+ <artifactId>slf4j-api</artifactId>
+ <version>1.6.1</version>
+ </dependency>
+ </dependencies>
+ </plugin>
+ </plugins>
</build>
</project>
--- /dev/null
+sphinx
+robotframework
skipsdist = true
[testenv:docs]
-deps = sphinx
-commands = sphinx-build -b html -n -d {envtmpdir}/doctrees ./docs/ {envtmpdir}/html
+deps = -rrequirements.txt
+commands = sphinx-build -b html -n -d {envtmpdir}/doctrees ./docs/ {toxinidir}/docs/_build/html
[testenv:docs-linkcheck]
-deps = sphinx
-commands = sphinx-build -b linkcheck -d {envtmpdir}/doctrees ./docs/ {envtmpdir}/linkcheck
+deps = -rrequirements.txt
+commands = sphinx-build -b linkcheck -d {envtmpdir}/doctrees ./docs/ {toxinidir}/docs/_build/linkcheck
Code Review / docs.git / commitdiff
