Merge pull request #15557 from idryzhov/remove-confd

*: remove confd plugin

configure.ac

@@ -751,8 +751,6 @@ AC_ARG_ENABLE([snmp],
   AS_HELP_STRING([--enable-snmp], [enable SNMP support for agentx]))
 AC_ARG_ENABLE([config_rollbacks],
   AS_HELP_STRING([--enable-config-rollbacks], [enable configuration rollbacks (requires sqlite3)]))
-AC_ARG_ENABLE([confd],
-  AS_HELP_STRING([--enable-confd=ARG], [enable confd integration]))
 AC_ARG_ENABLE([sysrepo],
   AS_HELP_STRING([--enable-sysrepo], [enable sysrepo integration]))
 AC_ARG_ENABLE([grpc],
@@ -2081,22 +2079,6 @@ if test "$enable_config_rollbacks" = "yes"; then
   ])
 fi
 
-dnl ---------------
-dnl confd
-dnl ---------------
-if test "$enable_confd" != "" -a "$enable_confd" != "no"; then
-   AC_CHECK_PROG([CONFD], [confd], [confd], [/bin/false], "${enable_confd}/bin")
-   if test "$CONFD" = "/bin/false"; then
-      AC_MSG_ERROR([confd was not found on your system.])]
-   fi
-   AC_CHECK_PROG([CONFDC], [confdc], [confdc], [/bin/false], "${enable_confd}/bin")
-   CONFD_CFLAGS="-I${enable_confd}/include -L${enable_confd}/lib"
-   AC_SUBST([CONFD_CFLAGS])
-   CONFD_LIBS="-lconfd"
-   AC_SUBST([CONFD_LIBS])
-   AC_DEFINE([HAVE_CONFD], [1], [Enable confd integration])
-fi
-
 dnl ---------------
 dnl sysrepo
 dnl ---------------
@@ -2766,7 +2748,6 @@ AM_CONDITIONAL([ENABLE_BGP_VNC], [test "$enable_bgp_vnc" != "no"])
 AM_CONDITIONAL([BGP_BMP], [$bgpd_bmp])
 dnl northbound
 AM_CONDITIONAL([SQLITE3], [$SQLITE3])
-AM_CONDITIONAL([CONFD], [test "$enable_confd" != ""])
 AM_CONDITIONAL([SYSREPO], [test "$enable_sysrepo" = "yes"])
 AM_CONDITIONAL([GRPC], [test "$enable_grpc" = "yes"])
 AM_CONDITIONAL([ZEROMQ], [test "$ZEROMQ" = "true"])

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
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

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

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
 ^^^^^^^
 

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.

doc/user/installation.rst

@@ -326,11 +326,6 @@ options from the list below.
 
    Build with configuration rollback support. Requires SQLite3.
 
-.. option:: --enable-confd=<dir>
-
-   Build the ConfD northbound plugin. Look for the libconfd libs and headers
-   in `dir`.
-
 .. option:: --enable-sysrepo
 
    Build the Sysrepo northbound plugin.

lib/lib_errors.c

@@ -307,24 +307,6 @@ static struct log_ref ferr_lib_err[] = {
 		.description = "The northbound subsystem, during initialization, has detected that a libyang plugin failed to be loaded",
 		.suggestion = "Check if the FRR libyang plugins were installed correctly in the system",
 	},
-	{
-		.code = EC_LIB_CONFD_INIT,
-		.title = "ConfD initialization error",
-		.description = "Upon startup FRR failed to properly initialize and startup the ConfD northbound plugin",
-		.suggestion = "Check if ConfD is installed correctly in the system. Also, check if the confd daemon is running.",
-	},
-	{
-		.code = EC_LIB_CONFD_DATA_CONVERT,
-		.title = "ConfD data conversion error",
-		.description = "An error has occurred while converting a ConfD data value (binary) to a string",
-		.suggestion = "Open an Issue with all relevant log files and restart FRR"
-	},
-	{
-		.code = EC_LIB_LIBCONFD,
-		.title = "libconfd error",
-		.description = "The northbound subsystem has detected that the libconfd library returned an error",
-		.suggestion = "Open an Issue with all relevant log files and restart FRR"
-	},
 	{
 		.code = EC_LIB_SYSREPO_INIT,
 		.title = "Sysrepo initialization error",

lib/lib_errors.h

@@ -65,9 +65,6 @@ enum lib_log_refs {
 	EC_LIB_NB_TRANSACTION_RECORD_FAILED,
 	EC_LIB_LIBYANG,
 	EC_LIB_LIBYANG_PLUGIN_LOAD,
-	EC_LIB_CONFD_INIT,
-	EC_LIB_CONFD_DATA_CONVERT,
-	EC_LIB_LIBCONFD,
 	EC_LIB_SYSREPO_INIT,
 	EC_LIB_SYSREPO_DATA_CONVERT,
 	EC_LIB_LIBSYSREPO,

lib/northbound.c

@@ -2403,8 +2403,6 @@ const char *nb_client_name(enum nb_client client)
 	switch (client) {
 	case NB_CLIENT_CLI:
 		return "CLI";
-	case NB_CLIENT_CONFD:
-		return "ConfD";
 	case NB_CLIENT_SYSREPO:
 		return "Sysrepo";
 	case NB_CLIENT_GRPC:

lib/northbound.h

@@ -621,11 +621,6 @@ struct nb_node {
 
 	/* Flags. */
 	uint8_t flags;
-
-#ifdef HAVE_CONFD
-	/* ConfD hash value corresponding to this YANG path. */
-	int confd_hash;
-#endif
 };
 /* The YANG container or list contains only config data. */
 #define F_NB_NODE_CONFIG_ONLY 0x01
@@ -700,7 +695,6 @@ enum nb_error {
 enum nb_client {
 	NB_CLIENT_NONE = 0,
 	NB_CLIENT_CLI,
-	NB_CLIENT_CONFD,
 	NB_CLIENT_SYSREPO,
 	NB_CLIENT_GRPC,
 	NB_CLIENT_PCEP,