.. note::
- Scripts are stored in the OpenDaylight distribution/bin folder, and
+ 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/.
+ 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
+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::
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
+file ``"custom_shard_configs.txt"`` in the same folder as this tool. Please see
that file for more details.
Example::
#. Copy the OpenDaylight distribution zip file to the machine.
#. Unzip the distribution.
-#. Open the following .conf files:
+#. Open the following configuration files:
- * configuration/initial/akka.conf
- * configuration/initial/module-shards.conf
+ * ``configuration/initial/akka.conf``
+ * ``configuration/initial/module-shards.conf``
#. In each configuration file, make the following changes:
.. note:: This step should use a different role on each node.
-#. Open the configuration/initial/module-shards.conf file and update the
+#. Open the ``configuration/initial/module-shards.conf`` file and update the
replicas so that each shard is replicated to all three nodes::
replicas = [
Cluster Monitoring
------------------
-OpenDaylight exposes shard information via MBeans, which can be explored with
-JConsole, VisualVM, or other JMX clients, or exposed via a REST API using
+OpenDaylight exposes shard information via ``MBeans``, which can be explored
+with ``JConsole``, VisualVM, or other JMX clients, or exposed via a REST API using
`Jolokia <https://jolokia.org/features-nb.html>`_, provided by the
``odl-jolokia`` Karaf feature. This is convenient, due to a significant focus
on REST in OpenDaylight.
-The basic URI that lists a schema of all available MBeans, but not their
+The basic URI that lists a schema of all available ``MBeans``, but not their
content itself is::
GET /jolokia/list
The ODLTools team is maintaining a Python based `tool
<https://github.com/opendaylight/odltools>`_,
-that takes advantage of the above MBeans exposed via Jolokia.
+that takes advantage of the above ``MBeans`` exposed via ``Jolokia``.
.. _cluster_admin_api:
This strategy is used by default, because it works well for most systems.
It will down the unreachable nodes if the current node is in the majority part
-based on the last known membership information. Otherwise down the reachable nodes,
-i.e. the own part. If the parts are of equal size the part containing the node with
-the lowest address is kept.
+based on the last known membership information. Otherwise down the reachable
+nodes, i.e. the own part. If the parts are of equal size the part containing the
+node with the lowest address is kept.
This strategy is a good choice when the number of nodes in the cluster change
dynamically and you can therefore not use static-quorum.
cluster, or when you can define a fixed number of nodes with a certain role.
* If there are unreachable nodes when starting up the cluster, before reaching
- this limit, the cluster may shut itself down immediately. This is not an issue
- if you start all nodes at approximately the same time or use the
- akka.cluster.min-nr-of-members to define required number of members before the
- leader changes member status of ‘Joining’ members to ‘Up’. You can tune the
- timeout after which downing decisions are made using the stable-after setting.
+ this limit, the cluster may shut itself down immediately.
+ This is not an issue if you start all nodes at approximately the same time or
+ use the ``akka.cluster.min-nr-of-members`` to define required number of
+ members before the leader changes member status of ‘Joining’ members to ‘Up’.
+ You can tune the timeout after which downing decisions are made using the
+ stable-after setting.
* You should not add more members to the cluster than quorum-size * 2 - 1.
- If the exceeded cluster size remains when a SBR decision is needed it will down
- all nodes because otherwise there is a risk that both sides may down each other
- and thereby form two separate clusters.
+ If the exceeded cluster size remains when a SBR decision is needed it will
+ down all nodes because otherwise there is a risk that both sides may down each
+ other and thereby form two separate clusters.
* If the cluster is split into 3 (or more) parts each part that is smaller than
- then configured quorum-size will down itself and possibly shutdown the whole cluster.
+ then configured quorum-size will down itself and possibly shutdown the whole
+ cluster.
* If more nodes than the configured quorum-size crash at the same time the other
running nodes will down themselves because they think that they are not in the
if the oldest was Leaving and not changed to Exiting then each part will shut down
itself, terminating the whole cluster.
-The decision can be based on nodes with a configured role instead of all nodes in
-the cluster.
+The decision can be based on nodes with a configured role instead of all nodes
+in the cluster.
Configuration::
The strategy named lease-majority is using a distributed lease (lock) to decide what
nodes that are allowed to survive. Only one SBR instance can acquire the lease make
-the decision to remain up. The other side will not be able to aquire the lease and
+the decision to remain up. The other side will not be able to acquire the lease and
will therefore down itself.
This strategy is very safe since coordination is added by an external arbiter.
Indirectly connected nodes
^^^^^^^^^^^^^^^^^^^^^^^^^^
-In a malfunctional network there can be situations where nodes are observed as
+In a malfunctioning network there can be situations where nodes are observed as
unreachable via some network links but they are still indirectly connected via
other nodes, i.e. it’s not a clean network partition (or node crash).
max-shard-data-store-executor-queue-size uint32 (1..max) 5000 The maximum queue size for each shard's data store executor.
shard-transaction-idle-timeout-in-minutes uint32 (1..max) 10 The maximum amount of time a shard transaction can be idle without receiving any messages before it self-destructs.
shard-snapshot-batch-count uint32 (1..max) 20000 The minimum number of entries to be present in the in-memory journal log before a snapshot is to be taken.
-shard-snapshot-data-threshold-percentage uint8 (1..100) 12 The percentage of Runtime.totalMemory() used by the in-memory journal log before a snapshot is to be taken
-shard-hearbeat-interval-in-millis uint16 (100..max) 500 The interval at which a shard will send a heart beat message to its remote shard.
+shard-snapshot-data-threshold-percentage uint8 (1..100) 12 The percentage of ``Runtime.totalMemory()`` used by the in-memory journal log before a snapshot is to be taken
+shard-heartbeat-interval-in-millis uint16 (100..max) 500 The interval at which a shard will send a heart beat message to its remote shard.
operation-timeout-in-seconds uint16 (5..max) 5 The maximum amount of time for akka operations (remote or local) to complete before failing.
shard-journal-recovery-log-batch-size uint32 (1..max) 5000 The maximum number of journal log entries to batch on recovery for a shard before committing to the data store.
shard-transaction-commit-timeout-in-seconds uint32 (1..max) 30 The maximum amount of time a shard transaction three-phase commit can be idle without receiving the next messages before it aborts the transaction
shard-isolated-leader-check-interval-in-millis uint32 (1..max) 5000 the interval at which the leader of the shard will check if its majority followers are active and term itself as isolated
============================================== ================= ======= ==============================================================================================================================================================================
-These configuration options are included in the etc/org.opendaylight.controller.cluster.datastore.cfg configuration file.
+These configuration options are included in the ``etc/org.opendaylight.controller.cluster.datastore.cfg`` configuration file.
questions correctly to ensure that the questions reach individuals
subscribed to the tag.
-#. Mail discuss@lists.opendaylight.org or dev@lists.opendaylight.org.
+#. Mail ``discuss@lists.opendaylight.org`` or ``dev@lists.opendaylight.org``.
#. Directly mail the PTL as indicated on the specific
`projects page <https://wiki-archive.opendaylight.org/view/Project_list>`_.
-#. IRC: Connect to #opendaylight or #opendaylight-meeting channel on freenode.
+#. IRC: Connect to ``#opendaylight`` or ``#opendaylight-meeting`` channel on ``freenode``.
The `Linux Foundation's IRC guide <https://docs.releng.linuxfoundation.org/en/latest/freenode.html>`_ may be helpful.
You'll need `an IRC client <https://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_clients#Operating_system_support>`_,
or can use `the freenode webchat <https://webchat.freenode.net/#opendaylight>`_,
or perhaps you'll `like IRCCloud <https://www.irccloud.com>`_.
-#. For infrastructure and release engineering queries, mail helpdesk@opendaylight.org.
- IRC: Connect to #lf-releng channel on freenode.
+#. For infrastructure and release engineering queries, mail ``helpdesk@opendaylight.org``.
+ IRC: Connect to ``#lf-releng`` channel on ``freenode``.
feature:list -i
-The decription of these features is in the project specific
+The description of these features is in the project specific
release notes :ref:`proj_rel_notes` section.
Karaf running on Windows 10
Error executing command: Can't install feature odl-restconf/0.0.0:
Could not start bundle mvn:org.fusesource.leveldbjni/leveldbjni-all/1.8-odl in feature(s) odl-akka-leveldb-0.7: The bundle "org.fusesource.leveldbjni.leveldbjni-all_1.8.0 [300]" could not be resolved. Reason: No match found for native code: META-INF/native/windows32/leveldbjni.dll; processor=x86; osname=Win32, META-INF/native/windows64/leveldbjni.dll; processor=x86-64; osname=Win32, META-INF/native/osx/libleveldbjni.jnilib; processor=x86; osname=macosx, META-INF/native/osx/libleveldbjni.jnilib; processor=x86-64; osname=macosx, META-INF/native/linux32/libleveldbjni.so; processor=x86; osname=Linux, META-INF/native/linux64/libleveldbjni.so; processor=x86-64; osname=Linux, META-INF/native/sunos64/amd64/libleveldbjni.so; processor=x86-64; osname=SunOS, META-INF/native/sunos64/sparcv9/libleveldbjni.so; processor=sparcv9; osname=SunOS
-Workaround is to add
+Workaround is to add::
org.osgi.framework.os.name = Win32
-to the karaf file
+to the karaf file::
etc/system.properties
the OpenDaylight controller, for example:
* A plugin that provides connectivity to devices via the OpenFlow protocols
- (openflowplugin).
+ (``openflowplugin``).
* A platform service such as Authentication, Authorization, and Accounting
(AAA).
* A network service providing VM connectivity for OpenStack (netvirt).
* Model Driven Service Abstraction Layer (MD-SAL). Yang models play a key role
in OpenDaylight and are used for:
- * Creating datastore schemas (tree based structure).
+ * Creating datastore schemata (tree based structure).
* Generating application REST API (RESTCONF).
* Automatic code generation (Java interfaces and Data Transfer Objects).
* 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.
-* The ability to dynamically modify permissions at runtime. This includes the
+* The ability to dynamically modify permissions at run-time. This includes the
ability to specify permissions by using code rather than a text configuration
file.
Securing the Karaf container
============================
-Apache Karaf is a OSGi-based runtime platform which provides a lightweight
+Apache Karaf is a OSGi-based run-time platform which provides a lightweight
container for OpenDaylight and applications. Apache Karaf uses
either Apache Felix Framework or Eclipse Equinox OSGi frameworks, and provide
additional features on top of the framework.
Securing OpenDaylight using AAA
===============================
-AAA stands for Authentication, Authorization, and Accounting. All three of
-these services can help improve the security posture of an OpenDaylight deployment.
+AAA stands for Authentication, Authorization, and Accounting.
+All three of these services can help improve the security posture of an
+OpenDaylight deployment.
The vast majority of OpenDaylight's northbound APIs (and all RESTCONF APIs) are
-protected by AAA by default when installing the +odl-restconf+ feature. In the
-cases that APIs are *not* protected by AAA, this will be noted in the
+protected by AAA by default when installing the ``+odl-restconf+`` feature.
+In the cases that APIs are *not* protected by AAA, this will be noted in the
per-project release notes.
By default, OpenDaylight has only one user account with the username and
have any special requirement beyond what is necessary to run the application or tool
to make REST calls.
-In some instances, OpenDaylight uses the `Xtend <https://www.eclipse.org/xtend/>`_ lamguage.
+In some instances, OpenDaylight uses the `Xtend <https://www.eclipse.org/xtend/>`_ language.
Even though Maven downloads all appropriate tools to build applications; additional plugins
may be required to support IDE.
AAA (Authentication, Authorization, and Accounting) are services that help
improve the security posture of an OpenDaylight deployment. By default,
the majority of OpenDaylight’s northbound APIs (and all RESTCONF APIs)
-are protected by AAA after installing the +odl-restconf+ feature.
+are protected by AAA after installing the ``+odl-restconf+`` feature.
Resolved Issues
===============
The plugin's **north-bound API** (``REST``/``Java``) provides to user:
-* Fully dynamic runtime standardized BGP configuration
+* Fully dynamic run-time standardized BGP configuration
* Read-only access to all RIBs
* Read-write programmable RIBs
-* Read-only reachability/linkstate topology view
+* Read-only reachability/link-state topology view
PCEP Plugin
-----------
Here is the link to the known issues exist in this release:
-`OpenDaylight JIRA Tickets - Known Issue <https://jira.opendaylight.org/issues/?jql=project+%3D+bgpcep+AND+type+%3D+Bug+AND+status+not+in+%28Resolved%2C+Done%2C+Closed%29+ORDER+BY+issuetype+DESC%2C+key+ASC>`_
\ No newline at end of file
+`OpenDaylight JIRA Tickets - Known Issue <https://jira.opendaylight.org/issues/?jql=project+%3D+bgpcep+AND+type+%3D+Bug+AND+status+not+in+%28Resolved%2C+Done%2C+Closed%29+ORDER+BY+issuetype+DESC%2C+key+ASC>`_
* - **Artifact**
- **Description**
- * - **Managed distribution** (e.g., karaf-<version>.tar.gz)
+ * - **Managed distribution** (e.g., ``karaf-<version>.tar.gz``)
- This includes the managed projects in OpenDaylight
(refer to, :ref:`managed-release`).
- * - **Common distribution** (e.g., opendaylight-<version>.tar.gz)
+ * - **Common distribution** (e.g., ``opendaylight-<version>.tar.gz``)
- This includes managed and self-managed projects
(refer to, :ref:`managed-release`).
- * - **ONAP distribution** (e.g., onap-karaf-<version>.tar.gz)
+ * - **ONAP distribution** (e.g., ``onap-karaf-<version>.tar.gz``)
- This is the distribution used in the ONAP CCSDK project.
The distribution project is also the placeholder for the distribution
Here is the link to the known issues exist in this release:
-`OpenDaylight JIRA Tickets - Known Issue <https://jira.opendaylight.org/issues/?jql=project+%3D+distribution+AND+type+%3D+Bug+AND+status+not+in+%28Resolved%2C+Done%2C+Closed%29+ORDER+BY+issuetype+DESC%2C+key+ASC>`_
\ No newline at end of file
+`OpenDaylight JIRA Tickets - Known Issue <https://jira.opendaylight.org/issues/?jql=project+%3D+distribution+AND+type+%3D+Bug+AND+status+not+in+%28Resolved%2C+Done%2C+Closed%29+ORDER+BY+issuetype+DESC%2C+key+ASC>`_
The InfraUtils project provides a low-level utility for use by other OpenDaylight projects, including:
* @Inject DI
-* Utils incl. org.opendaylight.infrautils.utils.concurrent
+* ``Utils`` incl. ``org.opendaylight.infrautils.utils.concurrent``
* Test Utilities
* Job Coordinator
* Ready Service
-* Integration Test Utilities (itestutils)
+* Integration Test Utilities (``itestutils``)
* Caches
-* Diagstatus
+* ``Diagstatus``
* Metrics
Behavior/Feature Changes
Here is the link to the known issues exist in this release:
-`OpenDaylight JIRA Tickets - Known Issue <https://jira.opendaylight.org/issues/?jql=project+%3D+infrautils+AND+type+%3D+Bug+AND+status+not+in+%28Resolved%2C+Done%2C+Closed%29+ORDER+BY+issuetype+DESC%2C+key+ASC>`_
\ No newline at end of file
+`OpenDaylight JIRA Tickets - Known Issue <https://jira.opendaylight.org/issues/?jql=project+%3D+infrautils+AND+type+%3D+Bug+AND+status+not+in+%28Resolved%2C+Done%2C+Closed%29+ORDER+BY+issuetype+DESC%2C+key+ASC>`_
Overview
========
-LISP (Locator ID Separation Protocol) Flow Mapping service provides mapping services,
-including LISP Map-Server and LISP Map-Resolver services that store and serve mapping
-data to dataplane nodes and to OpenDaylight applications. Mapping data can include
-mapping of virtual addresses to physical network addresses where the virtual nodes
-are reachable or hosted. Mapping data can also include a variety of routing policies
-including traffic engineering and load balancing. To leverage this service,
-OpenDaylight applications and services can use the northbound REST API to
-define the mappings and policies in the LISP Mapping Service. Dataplane
-devices capable of LISP control protocol can leverage this service through
-a southbound LISP plugin. LISP-enabled devices must be configured to use this
-OpenDaylight service, since their Map- Server and/or Map-Resolver.
-
-Southbound LISP plugin supports the LISP control protocol (that is, Map-Register,
-Map-Request, Map-Reply messages). It can also be used to register mappings in the
-OpenDaylight mapping service.
+LISP (Locator ID Separation Protocol) Flow Mapping service provides mapping
+services, including LISP Map-Server and LISP Map-Resolver services that store
+and serve mapping data to dataplane nodes and to OpenDaylight applications.
+Mapping data can include mapping of virtual addresses to physical network
+addresses where the virtual nodes are reachable or hosted.
+Mapping data can also include a variety of routing policies including traffic
+engineering and load balancing.
+To leverage this service, OpenDaylight applications and services can use the
+northbound REST API to define the mappings and policies in the LISP Mapping
+Service.
+Dataplane devices capable of LISP control protocol can leverage this service
+through a southbound LISP plugin.
+LISP-enabled devices must be configured to use this OpenDaylight service,
+since their Map- Server and/or Map-Resolver.
+
+Southbound LISP plugin supports the LISP control protocol
+(that is, Map-Register, Map-Request, Map-Reply messages).
+It can also be used to register mappings in the OpenDaylight mapping service.
Behavior/Feature Changes
========================
Here is the link to the known issues exist in this release:
-`OpenDaylight JIRA Tickets - Known Issue <https://jira.opendaylight.org/issues/?jql=project+%3D+lispflowmapping+AND+type+%3D+Bug+AND+status+not+in+%28Resolved%2C+Done%2C+Closed%29+ORDER+BY+issuetype+DESC%2C+key+ASC>`_
\ No newline at end of file
+`OpenDaylight JIRA Tickets - Known Issue <https://jira.opendaylight.org/issues/?jql=project+%3D+lispflowmapping+AND+type+%3D+Bug+AND+status+not+in+%28Resolved%2C+Done%2C+Closed%29+ORDER+BY+issuetype+DESC%2C+key+ASC>`_
The OpenFlow Plugin project provides the following functionality:
-* **OpenFlow 1.0/1.3 implementation project**: This provides the implementation of the
- OpenFlow 1.0 and OpenFlow 1.3 specification.
-* **ONF Approved Extensions Project**: This provides the implementation of following ONF
- OpenFlow 1.4 feature, which is approved as extensions for the OpenFlow 1.3
- specification:
+* **OpenFlow 1.0/1.3 implementation project**: This provides the implementation
+ of the OpenFlow 1.0 and OpenFlow 1.3 specification.
+* **ONF Approved Extensions Project**: This provides the implementation of
+ following ONF OpenFlow 1.4 feature, which is approved as extensions
+ for the OpenFlow 1.3 specification:
- * **Nicira Extensions Project**: This provides the implementation of the Nicira extensions.
- Some of the important extensions implemented are **Connection Tracking Extension**
- and **Group Add-Mod Extension**
+ * **Nicira Extensions Project**: This provides the implementation of the
+ ``Nicira`` extensions.
+ Some of the important extensions implemented are
+ **Connection Tracking Extension** and **Group Add-Mod Extension**
-* **OpenFlow-Based Applications Project**: This provides the following applications that user can
- leverage out-of-the-box in developing their application or as a direct end consumer:
+* **OpenFlow-Based Applications Project**: This provides the following
+ applications that user can leverage out-of-the-box in developing their
+ application or as a direct end consumer:
.. list-table:: OpenFlow-Based Applications
:widths: 15 55
plugin data models to the OpenFlow java models before sending it down the
wire to the device.
* - **Reconciliation**
- - Reconciles the state using Openflow 1.4 bundles.
+ - Reconciles the state using OpenFlow 1.4 bundles.
Behavior/Feature Changes
========================
Here is the link to the known issues exist in this release:
-`OpenDaylight JIRA Tickets - Known Issue <https://jira.opendaylight.org/issues/?jql=project+%3D+openflowplugin+AND+type+%3D+Bug+AND+status+not+in+%28Resolved%2C+Done%2C+Closed%29+ORDER+BY+issuetype+DESC%2C+key+ASC>`_
\ No newline at end of file
+`OpenDaylight JIRA Tickets - Known Issue <https://jira.opendaylight.org/issues/?jql=project+%3D+openflowplugin+AND+type+%3D+Bug+AND+status+not+in+%28Resolved%2C+Done%2C+Closed%29+ORDER+BY+issuetype+DESC%2C+key+ASC>`_
akka
analytics
BigInteger
+boolean
codebase
config
+Daexim
Disruptor
+dataplane
+datastore
datastores
deliverables
dev
GPG
hardcoded
helpdesk
+hostname
ietf
infrautils
+intra
Jenkins
Jira
jamoluhrsen
+jarfile
Karaf
karaf
lftools
Magnesium
mdsal
+microservice
+microservices
+millis
+mitigation
+mitigations
muxponders
netvirt
netconf
odlparent
ovs
ovsdb
+PCE
pre
+Resolvers
+Runtime
reachability
reconfigurable
+reconnection
reimplemented
+remediations
releng
renderer
rovarga
+runtime
+scalability
+stateful
submodule
switchponders
TCP
TSC
todo
tsc
+uint
uncheck
+unreachability
+untrusted
vTEP
virtualenv
yangtools
Code Review / docs.git / commitdiff