api
installing_opendaylight
release_notes
-
+ project-specific-guides/index
+.. _install_odl:
+
Installing OpenDaylight
=======================
--- /dev/null
+Project-Specific Installation Guides
+====================================
+
+.. toctree::
+ :maxdepth: 1
+
+ opflex
+ ovsdb-openstack
+ tsdr
+ vtn
--- /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
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!:
//////////////////////////
+++ /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
-== 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.
Code Review / docs.git / commitdiff