Rendering to the inventory-rendering model
- **Important**
+.. important::
When implementing your version of the topology-rendering model in
the Topology Processing Framework, the source file of the model
Step2 - Module and Feature Creation
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- **Important**
+.. important::
This and following steps are based on the `model specific
approach <#_model_specific_approach>`__ in the Topology Processing
Inventory Rendering). In the case of the provider class, we put the
abbreviation at the end.
- **Important**
+.. important::
- In the next sections, we use the terms TopologyRequestListener,
TopologyRequestHandler, etc. without a prepended or appended
the rendering operator just wraps each received UnderlayItem to
OverlayItem and sends them to write.
- **Important**
+.. important::
For purposes of topology rendering from inventory to
network-topology, there are misused fields in UnderlayItem as
- To an optical network: The port maybe *abstract*, yet the optical
wavelength is *concrete*.
- **Note**
+.. note::
*This is a very domain specific analogy, tied to something most
readers will understand. It in no way implies the **GBP** should be
- REST API
- **Note**
+.. note::
When using the :ref:`Neutron mapper <gbp-neutron>` feature, everything is
managed transparently via Neutron.
Configuring OpenFlow Overlay via REST
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- **Note**
+.. note::
Please see the :ref:`UX <gbp-ux>` section on how to configure **GBP** via
the GUI.
}
}
- **Note**
+.. note::
The usage of "port-name" preceded by "ofoverlay". In OpenDaylight,
base datastore objects can be *augmented*. In **GBP**, the base
data/RPC/notifications described by a YANG model that is implemented by
the device.**
- **Tip**
+.. tip::
NETCONF southbound can be activated by installing
``odl-netconf-connector-all`` Karaf feature.
**For such devices you only need to put the schema into folder
cache/schema inside your Karaf distribution.**
- **Important**
+.. important::
The file with YANG schema for ietf-inet-types has to be called
ietf-inet-types@2010-09-24.yang. It is the required naming format of
new NETCONF connectors both through the NETCONF server for MD-SAL (port
2830) or RESTCONF. This guide focuses on RESTCONF.
- **Tip**
+.. tip::
To enable NETCONF connector configuration through MD-SAL install
either the ``odl-netconf-topology`` or
To spawn NETCONF connectors that are cluster-aware you need to install
the ``odl-netconf-clustered-topology`` karaf feature.
- **Warning**
+.. warning::
The ``odl-netconf-topology`` and ``odl-netconf-clustered-topology``
features are considered **INCOMPATIBLE**. They both manage the same
Should return 200 response code with no body.
- **Tip**
+.. tip::
This call is transformed into a couple of NETCONF RPCs. Resulting
NETCONF RPCs that go directly to the device can be found in the
Notifications over NETCONF are not supported in the Boron release.
- **Tip**
+.. tip::
Install NETCONF northbound for MD-SAL by installing feature:
``odl-netconf-mdsal`` in karaf. Default binding port is **2830**.
These jars are part of OpenDaylight’s controller project and are built
from the NETCONF codebase in OpenDaylight.
- **Tip**
+.. tip::
Download testtool from OpenDaylight Nexus at:
https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/netconf/netconf-testtool/1.1.0-Boron/
- perf-client.jar - RESTCONF stress/performance measuring tool
- **Tip**
+.. tip::
Each executable tool provides help. Just invoke ``java -jar
<name-of-the-tool.jar> --help``
http://localhost:8181/restconf/operational/network-topology:network-topology/topology/topology-netconf/node/17830-sim-device/yang-ext:mount/
- **Warning**
+.. warning::
Data will be mirrored in operational datastore only when using the
default simple datastore.
Code Review / docs.git / commitdiff