Merging upstream version 10.1.

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

6 files changed, 26 insertions, 70 deletions

diff --git a/doc/developer/northbound/advanced-topics.rst b/doc/developer/northbound/advanced-topics.rst
index edfc10b..eb75602 100644
--- a/doc/developer/northbound/advanced-topics.rst
+++ b/doc/developer/northbound/advanced-topics.rst
@@ -12,8 +12,7 @@ Auto-generated CLI commands
 In order to have less code to maintain, it should be possible to write a
 tool that auto-generates CLI commands based on the FRR YANG models. As a
 matter of fact, there are already a number of NETCONF-based CLIs that do
-exactly that (e.g. `Clixon <https://github.com/clicon/clixon>`__,
-ConfD’s CLI).
+exactly that (e.g. `Clixon <https://github.com/clicon/clixon>`__).
 
 The problem however is that there isn’t an exact one-to-one mapping
 between the existing CLI commands and the corresponding YANG nodes from
@@ -27,11 +26,6 @@ command for each YANG leaf, (leaf-)list and presence-container. The
 ripd’s ``timers basic`` command, for instance, would become three
 different commands, which would be undesirable.
 
-   This Tail-f’s®
-   `document <http://info.tail-f.com/hubfs/Whitepapers/Tail-f_ConfD-CLI__Cfg_Mode_App_Note_Rev%20C.pdf>`__
-   shows how to customize ConfD auto-generated CLI commands using YANG
-   annotations.
-
 The good news is that *libyang* allows users to create plugins to
 implement their own YANG extensions, which can be used to implement CLI
 annotations. If done properly, a CLI generator can save FRR developers
@@ -76,8 +70,8 @@ Example of how this feature could be provided in the CLI:
 ``commit confirmed [minutes <1-60>]``. The ability to do confirmed
 commits should also be exposed in the northbound API so that the
 northbound plugins can also take advantage of it (in the case of the
-Sysrepo and ConfD plugins, confirmed commits are implemented externally
-in the *netopeer2-server* and *confd* daemons, respectively).
+Sysrepo plugin, confirmed commit is implemented externally in the
+*netopeer2-server* daemon).
 
 Proposed feature: enable/disable configuration commands/sections
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/developer/northbound/architecture.rst b/doc/developer/northbound/architecture.rst
index 5fd89c3..4e84f1d 100644
--- a/doc/developer/northbound/architecture.rst
+++ b/doc/developer/northbound/architecture.rst
@@ -116,7 +116,7 @@ multitude of different management APIs, all of them connected to the
 northbound layer of the FRR daemons. By default, only the CLI interface
 is compiled built-in in the FRR daemons. The other management interfaces
 are provided as optional plugins and need to be loaded during the daemon
-initialization (e.g. *zebra -M confd*). This design makes it possible to
+initialization (e.g. *zebra -M grpc*). This design makes it possible to
 integrate FRR with different NETCONF solutions without introducing
 vendor lock-in. The [[Plugins - Writing Your Own]] page explains how to
 write custom northbound plugins that can be tailored to all needs
diff --git a/doc/developer/northbound/demos.rst b/doc/developer/northbound/demos.rst
index 8a0f6ad..7c5ae0c 100644
--- a/doc/developer/northbound/demos.rst
+++ b/doc/developer/northbound/demos.rst
@@ -8,23 +8,3 @@ This short demo shows some of the capabilities of the new transactional
 CLI:
 
 |asciicast1|
-
-ConfD + NETCONF + Cisco YDK
----------------------------
-
-This is a very simple demo of *ripd* being configured by a python
-script. The script uses NETCONF to communicate with *ripd*, which has
-the ConfD plugin loaded. The most interesting part, however, is the fact
-that the python script is not using handcrafted XML payloads to
-configure *ripd*. Instead, the script is using python bindings generated
-using Cisco’s YANG Development Kit (YDK).
-
--  Script used in the demo:
-   https://gist.github.com/rwestphal/defa9bd1ccf216ab082d4711ae402f95
-
-|asciicast2|
-
-.. |asciicast1| image:: https://asciinema.org/a/jL0BS5HfP2kS6N1HfgsZvfZk1.png
-   :target: https://asciinema.org/a/jL0BS5HfP2kS6N1HfgsZvfZk1
-.. |asciicast2| image:: https://asciinema.org/a/VfMElNxsjLcdvV7484E6ChxWv.png
-   :target: https://asciinema.org/a/VfMElNxsjLcdvV7484E6ChxWv
diff --git a/doc/developer/northbound/links.rst b/doc/developer/northbound/links.rst
index 6cec176..e8fb327 100644
--- a/doc/developer/northbound/links.rst
+++ b/doc/developer/northbound/links.rst
@@ -195,14 +195,6 @@ pyangbind
 -  GitHub page: https://github.com/robshakir/pyangbind
 -  Documentation: http://pynms.io/pyangbind/
 
-ConfD
-^^^^^
-
--  Official webpage (for ConfD Basic):
-   http://www.tail-f.com/confd-basic/
--  Training Videos: http://www.tail-f.com/confd-training-videos/
--  Forum: http://discuss.tail-f.com/
-
 Sysrepo
 ^^^^^^^
 
diff --git a/doc/developer/northbound/operational-data-rpcs-and-notifications.rst b/doc/developer/northbound/operational-data-rpcs-and-notifications.rst
index 5cb70ca..07f92c2 100644
--- a/doc/developer/northbound/operational-data-rpcs-and-notifications.rst
+++ b/doc/developer/northbound/operational-data-rpcs-and-notifications.rst
@@ -10,10 +10,10 @@ Operational data
 ~~~~~~~~~~~~~~~~
 
 Writing API-agnostic code for YANG-modeled operational data is
-challenging. ConfD and Sysrepo, for instance, have completely different
-APIs to fetch operational data. So how can we write API-agnostic
-callbacks that can be used by both the ConfD and Sysrepo plugins, and
-any other northbound client that might be written in the future?
+challenging. Sysrepo, for instance, has completely different API to
+fetch operational data. So how can we write API-agnostic callbacks
+that can be used by both the Sysrepo plugin, and any other northbound
+client that might be written in the future?
 
 As an additional requirement, the callbacks must be designed in a way
 that makes in-place XPath filtering possible. As an example, a
@@ -94,27 +94,18 @@ in the northbound architecture:
             */
            void *(*lookup_entry)(struct yang_list_keys *keys);
 
-These callbacks were designed to provide maximum flexibility, and borrow
-a lot of ideas from the ConfD API. Each callback does one and only one
-task, they are indivisible primitives that can be combined in several
-different ways to iterate over operational data. The extra flexibility
-certainly has a performance cost, but it’s the price to pay if we want
-to expose FRR operational data using several different management
-interfaces (e.g. NETCONF via either ConfD or Sysrepo+Netopeer2). In the
+These callbacks were designed to provide maximum flexibility. Each
+callback does one and only one task, they are indivisible primitives
+that can be combined in several different ways to iterate over operational
+data. The extra flexibility certainly has a performance cost, but it’s the
+price to pay if we want to expose FRR operational data using several
+different management interfaces (e.g. Sysrepo+Netopeer2). In the
 future it might be possible to introduce optional callbacks that do
 things like returning multiple objects at once. They would provide
 enhanced performance when iterating over large lists, but their use
 would be limited by the northbound plugins that can be integrated with
 them.
 
-   NOTE: using the northbound callbacks as a base, the ConfD plugin can
-   provide up to 100 objects between each round trip between FRR and the
-   *confd* daemon. Preliminary tests showed FRR taking ~7 seconds
-   (asynchronously, without blocking the main pthread) to return a RIP
-   table containing 100k routes to a NETCONF client connected to *confd*
-   (JSON was used as the encoding format). Work needs to be done to find
-   the bottlenecks and optimize this operation.
-
 The [[Plugins - Writing Your Own]] page explains how the northbound
 plugins can fetch operational data using the aforementioned northbound
 callbacks, and how in-place XPath filtering can be implemented.
@@ -351,10 +342,10 @@ are being iterated over. If that is not done, the list entry returned by
 this callback can become a dangling pointer when used in another
 callback.
 
-Currently the ConfD and Sysrepo plugins run only in the main pthread.
-The plan in the short-term is to introduce a separate pthread only for
-handling operational data, and use the main pthread only for handling
-configuration changes, RPCs and notifications.
+Currently the Sysrepo plugin runs only in the main pthread. The plan in the
+short-term is to introduce a separate pthread only for handling operational
+data, and use the main pthread only for handling configuration changes,
+RPCs and notifications.
 
 RPCs and Actions
 ~~~~~~~~~~~~~~~~
@@ -396,8 +387,8 @@ some EXEC-level commands using YANG so that their functionality is
 exposed to other management interfaces other than the CLI. As an
 example, if the ``clear bgp`` command is modeled using a YANG RPC, and a
 corresponding ``rpc`` callback is written, then it should be possible to
-clear BGP neighbors using NETCONF and RESTCONF with that RPC (the ConfD
-and Sysrepo plugins have full support for YANG RPCs and actions).
+clear BGP neighbors using NETCONF and RESTCONF with that RPC (the Sysrepo
+plugin has full support for YANG RPCs and actions).
 
 Here’s an example of a very simple RPC modeled using YANG:
 
@@ -568,8 +559,7 @@ Now sending the *authentication-failure* YANG notification should be as
 simple as calling the above function and provide the appropriate
 interface name. The notification will be processed by all northbound
 plugins that subscribed a callback to the ``nb_notification_send`` hook.
-The ConfD and Sysrepo plugins, for instance, use this hook to relay the
-notifications to the *confd*/*sysrepod* daemons, which can generate
-NETCONF notifications to subscribed clients. When no northbound plugin
-is loaded, ``nb_notification_send()`` doesn’t do anything and the
-notifications are ignored.
+The Sysrepo plugin, for instance, uses this hook to relay the notifications
+to the *sysrepod* daemon, which can generate NETCONF notifications to subscribed
+clients. When no northbound plugin is loaded, ``nb_notification_send()`` doesn’t
+do anything and the notifications are ignored.
diff --git a/doc/developer/northbound/plugins-sysrepo.rst b/doc/developer/northbound/plugins-sysrepo.rst
index 0cfdb82..f4df68c 100644
--- a/doc/developer/northbound/plugins-sysrepo.rst
+++ b/doc/developer/northbound/plugins-sysrepo.rst
@@ -32,7 +32,7 @@ libyang
    cd libyang
    git checkout v2.1.148
    mkdir build; cd build
-   cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr \
+   cmake --install-prefix /usr \
          -DCMAKE_BUILD_TYPE:String="Release" ..
    make
    sudo make install
@@ -51,7 +51,7 @@ Sysrepo
    cd sysrepo/
    git checkout v2.2.150
    mkdir build; cd build
-   cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr \
+   cmake --install-prefix /usr \
          -DCMAKE_BUILD_TYPE:String="Release" ..
    make
    sudo make install