Merge "Fix bold embedded links."
[docs.git] / docs / developer-guide / controller.rst
index ade88739f08716ef1e7efc96882808573a2b67f3..85dbc9eba3bdafa363431a099b843e3ff4fc59eb 100644 (file)
@@ -1,3 +1,5 @@
+.. _controller-dev-guide:
+
 Controller
 ==========
 
@@ -26,12 +28,12 @@ The OpenDaylight Controller relies on the following technologies:
 The OpenDaylight Controller provides following model-driven subsystems
 as a foundation for Java applications:
 
--  **`Config Subsystem <#_config_subsystem>`__** - an activation,
+-  :ref:`config_subsystem` - an activation,
    dependency-injection and configuration framework, which allows
    two-phase commits of configuration and dependency-injection, and
    allows for run-time rewiring.
 
--  **`MD-SAL <#_md_sal_overview>`__** - messaging and data storage
+-  :ref:`MD-SAL <mdsal_dev_guide>` - messaging and data storage
    functionality for data, notifications and RPCs modeled by application
    developers. MD-SAL uses YANG as the modeling for both interface and
    data definitions, and provides a messaging and data-centric runtime
@@ -183,8 +185,8 @@ MD-SAL **Data Broker** provides transactional access to conceptual
     this is state of controller, applications and also external systems
     (network devices).
 
-**Transactions** provide **`stable and isolated
-view <#_transaction_isolation>`__** from other currently running
+**Transactions** provide :ref:`stable and isolated
+view <transaction_isolation>` from other currently running
 transactions. The state of running transaction and underlying data tree
 is not affected by other concurrently running transactions.
 
@@ -235,8 +237,8 @@ for the conceptual data trees.
    using ``put``, ``merge`` and/or ``delete``.
 
 3. application finishes transaction using
-   ```submit()`` <#_submitting_transaction>`__, which seals transaction
-   and submits it to be processed.
+   ``submit()``, which :ref:`seals transaction
+   and submits <submitting_transaction>` it to be processed.
 
 4. application observes the result of the transaction commit using
    either blocking or asynchronous calls.
@@ -247,12 +249,12 @@ it’s state and underlying data tree are not affected by other
 concurrently running transactions.
 
 Write transactions are **isolated** from other concurrent write
-transactions. All **`writes are local <#_transaction_local_state>`__**
+transactions. All :ref:`writes are local <transaction_local_state>`
 to the transaction and represents only a **proposal of state change**
 for data tree and **are not visible** to any other concurrently running
 transactions (including read-only transactions).
 
-The transaction **`commit may fail <#_commit_failure_scenarios>`__** due
+The transaction :ref:`commit may fail <commit_failure_scenarios>` due
 to failing verification of data or concurrent transaction modifying and
 affected data in an incompatible way.
 
@@ -288,6 +290,8 @@ delete
 
     Removes a whole subtree from a specified path.
 
+.. _submitting_transaction:
+
 Submitting transaction
 ^^^^^^^^^^^^^^^^^^^^^^
 
@@ -350,6 +354,8 @@ If application need to block till commit is finished it may use
 
 -  Catches ``TransactionCommitFailedException`` and logs it.
 
+.. _transaction_local_state:
+
 Transaction local state
 ^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -386,6 +392,8 @@ Let assume initial state of data tree for ``PATH`` is ``A``.
 -  Read will return value ``C`` for ``PATH``, since previous write
    occurred in same transaction.
 
+.. _transaction_isolation:
+
 Transaction isolation
 ~~~~~~~~~~~~~~~~~~~~~
 
@@ -444,6 +452,8 @@ Lets assume initial state of data tree for ``PATH`` is ``A``.
     ``Futures#addCallback(ListenableFuture, FutureCallback)`` to listen
     asynchronously for result.
 
+.. _commit_failure_scenarios:
+
 Commit failure scenarios
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -843,6 +853,17 @@ Line 112: We register salFlowService1 as implementation for nodeOne.
 The salFlowService1 will be executed only for RPCs which contains
 Instance Identifier for foo:node:1.
 
+RPCs and cluster
+^^^^^^^^^^^^^^^^
+
+In case there is is only a single provider of an RPC in the cluster
+the RPC registration is propagated to other nodes via Gossip protocol
+and the RPC calls from other nodes are correctly routed to the
+provider. Since the registrations are not expected to change rapidly
+there is a latency of about 1 second until the registration is reflected
+on the remote nodes.
+
+
 OpenDaylight Controller MD-SAL: RESTCONF
 ----------------------------------------
 
@@ -1657,6 +1678,8 @@ RESTCONF.
     WebSocket client
     applications <https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_client_applications>`__
 
+.. _config_subsystem:
+
 Config Subsystem
 ----------------