2023-02-08 13:17:09 +01:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2017-12-07 20:31:48 +01:00
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2018 NetDEF, Inc.
|
|
|
|
|
* Renato Westphal
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _FRR_NORTHBOUND_CLI_H_
|
|
|
|
|
#define _FRR_NORTHBOUND_CLI_H_
|
|
|
|
|
|
|
|
|
|
#include "northbound.h"
|
|
|
|
|
|
2019-02-07 23:10:31 +01:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
extern "C" {
|
|
|
|
|
#endif
|
|
|
|
|
|
2017-12-07 20:31:48 +01:00
|
|
|
/* Possible formats in which a configuration can be displayed. */
|
|
|
|
|
enum nb_cfg_format {
|
|
|
|
|
NB_CFG_FMT_CMDS = 0,
|
|
|
|
|
NB_CFG_FMT_JSON,
|
|
|
|
|
NB_CFG_FMT_XML,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
extern struct nb_config *vty_shared_candidate_config;
|
|
|
|
|
|
lib, ripd: rework API for converted CLI commands
When editing the candidate configuration, the northbound must ensure
that either all changes made by a command are accepted or none are.
This is done to prevent inconsistent states where only parts of a
command are applied in the event any error happens.
The previous API for converted commands, the nb_cli_cfg_change()
function, required callers to pass an array containing all changes
that needed to be applied in the candidate configuration. The
problem with this API is that it was very inconvenient for complex
commands, which change different configuration options depending
on several factors. This required users to manipulate the array
of configuration changes using low-level primitives, making it
complicated to implement some commands.
To solve this problem, introduce a new API based on the two following
functions:
- nb_cli_enqueue_change()
- nb_cli_apply_changes()
The first function is used to enqueue configuration changes, one
at time. Then the nb_cli_apply_changes() function is used to apply
all the enqueued configuration changes.
To implement this, a static-sized array was allocated in the "vty"
structure, along with a counter of enqueued changes. This eliminates
the need to declare an array of configuration changes in every
converted CLI command, simplifying things quite considerably.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2018-11-26 18:30:14 +01:00
|
|
|
/*
|
|
|
|
|
* Enqueue change to be applied in the candidate configuration.
|
|
|
|
|
*
|
|
|
|
|
* vty
|
|
|
|
|
* The vty context.
|
|
|
|
|
*
|
|
|
|
|
* xpath
|
|
|
|
|
* XPath (absolute or relative) of the configuration option being edited.
|
|
|
|
|
*
|
|
|
|
|
* operation
|
2023-10-06 14:01:16 +02:00
|
|
|
* Operation to apply (either NB_OP_CREATE, NB_OP_MODIFY or NB_OP_DESTROY).
|
lib, ripd: rework API for converted CLI commands
When editing the candidate configuration, the northbound must ensure
that either all changes made by a command are accepted or none are.
This is done to prevent inconsistent states where only parts of a
command are applied in the event any error happens.
The previous API for converted commands, the nb_cli_cfg_change()
function, required callers to pass an array containing all changes
that needed to be applied in the candidate configuration. The
problem with this API is that it was very inconvenient for complex
commands, which change different configuration options depending
on several factors. This required users to manipulate the array
of configuration changes using low-level primitives, making it
complicated to implement some commands.
To solve this problem, introduce a new API based on the two following
functions:
- nb_cli_enqueue_change()
- nb_cli_apply_changes()
The first function is used to enqueue configuration changes, one
at time. Then the nb_cli_apply_changes() function is used to apply
all the enqueued configuration changes.
To implement this, a static-sized array was allocated in the "vty"
structure, along with a counter of enqueued changes. This eliminates
the need to declare an array of configuration changes in every
converted CLI command, simplifying things quite considerably.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2018-11-26 18:30:14 +01:00
|
|
|
*
|
|
|
|
|
* value
|
|
|
|
|
* New value of the configuration option. Should be NULL for typeless YANG
|
|
|
|
|
* data (e.g. presence-containers). For convenience, NULL can also be used
|
|
|
|
|
* to restore a leaf to its default value.
|
|
|
|
|
*/
|
|
|
|
|
extern void nb_cli_enqueue_change(struct vty *vty, const char *xpath,
|
|
|
|
|
enum nb_operation operation,
|
|
|
|
|
const char *value);
|
|
|
|
|
|
|
|
|
|
/*
|
2021-05-28 21:16:18 +02:00
|
|
|
* Apply enqueued changes to the candidate configuration, do not batch,
|
|
|
|
|
* and apply any pending commits along with the currently enqueued.
|
|
|
|
|
*
|
|
|
|
|
* vty
|
|
|
|
|
* The vty context.
|
|
|
|
|
*
|
|
|
|
|
* xpath_base_fmt
|
|
|
|
|
* Prepend the given XPath (absolute or relative) to all enqueued
|
|
|
|
|
* configuration changes. This is an optional parameter.
|
|
|
|
|
*
|
|
|
|
|
* Returns:
|
|
|
|
|
* CMD_SUCCESS on success, CMD_WARNING_CONFIG_FAILED otherwise.
|
|
|
|
|
*/
|
|
|
|
|
extern int nb_cli_apply_changes_clear_pending(struct vty *vty,
|
2023-01-26 14:21:02 +01:00
|
|
|
const char *xpath_base_fmt, ...)
|
|
|
|
|
PRINTFRR(2, 3);
|
2021-05-28 21:16:18 +02:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Apply enqueued changes to the candidate configuration, this function
|
|
|
|
|
* may not immediately apply the changes, instead adding them to a pending
|
|
|
|
|
* queue.
|
lib, ripd: rework API for converted CLI commands
When editing the candidate configuration, the northbound must ensure
that either all changes made by a command are accepted or none are.
This is done to prevent inconsistent states where only parts of a
command are applied in the event any error happens.
The previous API for converted commands, the nb_cli_cfg_change()
function, required callers to pass an array containing all changes
that needed to be applied in the candidate configuration. The
problem with this API is that it was very inconvenient for complex
commands, which change different configuration options depending
on several factors. This required users to manipulate the array
of configuration changes using low-level primitives, making it
complicated to implement some commands.
To solve this problem, introduce a new API based on the two following
functions:
- nb_cli_enqueue_change()
- nb_cli_apply_changes()
The first function is used to enqueue configuration changes, one
at time. Then the nb_cli_apply_changes() function is used to apply
all the enqueued configuration changes.
To implement this, a static-sized array was allocated in the "vty"
structure, along with a counter of enqueued changes. This eliminates
the need to declare an array of configuration changes in every
converted CLI command, simplifying things quite considerably.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2018-11-26 18:30:14 +01:00
|
|
|
*
|
|
|
|
|
* vty
|
|
|
|
|
* The vty context.
|
|
|
|
|
*
|
|
|
|
|
* xpath_base_fmt
|
|
|
|
|
* Prepend the given XPath (absolute or relative) to all enqueued
|
2019-01-03 01:32:13 +01:00
|
|
|
* configuration changes. This is an optional parameter.
|
lib, ripd: rework API for converted CLI commands
When editing the candidate configuration, the northbound must ensure
that either all changes made by a command are accepted or none are.
This is done to prevent inconsistent states where only parts of a
command are applied in the event any error happens.
The previous API for converted commands, the nb_cli_cfg_change()
function, required callers to pass an array containing all changes
that needed to be applied in the candidate configuration. The
problem with this API is that it was very inconvenient for complex
commands, which change different configuration options depending
on several factors. This required users to manipulate the array
of configuration changes using low-level primitives, making it
complicated to implement some commands.
To solve this problem, introduce a new API based on the two following
functions:
- nb_cli_enqueue_change()
- nb_cli_apply_changes()
The first function is used to enqueue configuration changes, one
at time. Then the nb_cli_apply_changes() function is used to apply
all the enqueued configuration changes.
To implement this, a static-sized array was allocated in the "vty"
structure, along with a counter of enqueued changes. This eliminates
the need to declare an array of configuration changes in every
converted CLI command, simplifying things quite considerably.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2018-11-26 18:30:14 +01:00
|
|
|
*
|
|
|
|
|
* Returns:
|
|
|
|
|
* CMD_SUCCESS on success, CMD_WARNING_CONFIG_FAILED otherwise.
|
|
|
|
|
*/
|
|
|
|
|
extern int nb_cli_apply_changes(struct vty *vty, const char *xpath_base_fmt,
|
2023-01-26 14:21:02 +01:00
|
|
|
...) PRINTFRR(2, 3);
|
lib, ripd: rework API for converted CLI commands
When editing the candidate configuration, the northbound must ensure
that either all changes made by a command are accepted or none are.
This is done to prevent inconsistent states where only parts of a
command are applied in the event any error happens.
The previous API for converted commands, the nb_cli_cfg_change()
function, required callers to pass an array containing all changes
that needed to be applied in the candidate configuration. The
problem with this API is that it was very inconvenient for complex
commands, which change different configuration options depending
on several factors. This required users to manipulate the array
of configuration changes using low-level primitives, making it
complicated to implement some commands.
To solve this problem, introduce a new API based on the two following
functions:
- nb_cli_enqueue_change()
- nb_cli_apply_changes()
The first function is used to enqueue configuration changes, one
at time. Then the nb_cli_apply_changes() function is used to apply
all the enqueued configuration changes.
To implement this, a static-sized array was allocated in the "vty"
structure, along with a counter of enqueued changes. This eliminates
the need to declare an array of configuration changes in every
converted CLI command, simplifying things quite considerably.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2018-11-26 18:30:14 +01:00
|
|
|
|
|
|
|
|
/*
|
2024-03-18 18:08:23 +01:00
|
|
|
* Add an input child node for an RPC or an action.
|
|
|
|
|
*
|
|
|
|
|
* vty
|
|
|
|
|
* The vty context.
|
|
|
|
|
*
|
|
|
|
|
* xpath
|
|
|
|
|
* XPath of the child being added, relative to the input container.
|
|
|
|
|
*
|
|
|
|
|
* value
|
|
|
|
|
* Value of the child being added. Can be NULL for containers and leafs of
|
|
|
|
|
* type 'empty'.
|
|
|
|
|
*/
|
|
|
|
|
extern int nb_cli_rpc_enqueue(struct vty *vty, const char *xpath,
|
|
|
|
|
const char *value);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Execute a YANG RPC or Action using the enqueued input parameters.
|
lib, ripd: rework API for converted CLI commands
When editing the candidate configuration, the northbound must ensure
that either all changes made by a command are accepted or none are.
This is done to prevent inconsistent states where only parts of a
command are applied in the event any error happens.
The previous API for converted commands, the nb_cli_cfg_change()
function, required callers to pass an array containing all changes
that needed to be applied in the candidate configuration. The
problem with this API is that it was very inconvenient for complex
commands, which change different configuration options depending
on several factors. This required users to manipulate the array
of configuration changes using low-level primitives, making it
complicated to implement some commands.
To solve this problem, introduce a new API based on the two following
functions:
- nb_cli_enqueue_change()
- nb_cli_apply_changes()
The first function is used to enqueue configuration changes, one
at time. Then the nb_cli_apply_changes() function is used to apply
all the enqueued configuration changes.
To implement this, a static-sized array was allocated in the "vty"
structure, along with a counter of enqueued changes. This eliminates
the need to declare an array of configuration changes in every
converted CLI command, simplifying things quite considerably.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2018-11-26 18:30:14 +01:00
|
|
|
*
|
2020-10-04 00:34:33 +02:00
|
|
|
* vty
|
|
|
|
|
* The vty terminal to dump any error.
|
|
|
|
|
*
|
lib, ripd: rework API for converted CLI commands
When editing the candidate configuration, the northbound must ensure
that either all changes made by a command are accepted or none are.
This is done to prevent inconsistent states where only parts of a
command are applied in the event any error happens.
The previous API for converted commands, the nb_cli_cfg_change()
function, required callers to pass an array containing all changes
that needed to be applied in the candidate configuration. The
problem with this API is that it was very inconvenient for complex
commands, which change different configuration options depending
on several factors. This required users to manipulate the array
of configuration changes using low-level primitives, making it
complicated to implement some commands.
To solve this problem, introduce a new API based on the two following
functions:
- nb_cli_enqueue_change()
- nb_cli_apply_changes()
The first function is used to enqueue configuration changes, one
at time. Then the nb_cli_apply_changes() function is used to apply
all the enqueued configuration changes.
To implement this, a static-sized array was allocated in the "vty"
structure, along with a counter of enqueued changes. This eliminates
the need to declare an array of configuration changes in every
converted CLI command, simplifying things quite considerably.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2018-11-26 18:30:14 +01:00
|
|
|
* xpath
|
|
|
|
|
* XPath of the YANG RPC or Action node.
|
|
|
|
|
*
|
2024-03-18 18:08:23 +01:00
|
|
|
* output_p
|
|
|
|
|
* A pointer to the libyang data node that will hold the output data tree.
|
|
|
|
|
* It can be set to NULL if the caller is not interested in processing the
|
|
|
|
|
* output. The caller is responsible for freeing the output data tree.
|
lib, ripd: rework API for converted CLI commands
When editing the candidate configuration, the northbound must ensure
that either all changes made by a command are accepted or none are.
This is done to prevent inconsistent states where only parts of a
command are applied in the event any error happens.
The previous API for converted commands, the nb_cli_cfg_change()
function, required callers to pass an array containing all changes
that needed to be applied in the candidate configuration. The
problem with this API is that it was very inconvenient for complex
commands, which change different configuration options depending
on several factors. This required users to manipulate the array
of configuration changes using low-level primitives, making it
complicated to implement some commands.
To solve this problem, introduce a new API based on the two following
functions:
- nb_cli_enqueue_change()
- nb_cli_apply_changes()
The first function is used to enqueue configuration changes, one
at time. Then the nb_cli_apply_changes() function is used to apply
all the enqueued configuration changes.
To implement this, a static-sized array was allocated in the "vty"
structure, along with a counter of enqueued changes. This eliminates
the need to declare an array of configuration changes in every
converted CLI command, simplifying things quite considerably.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2018-11-26 18:30:14 +01:00
|
|
|
*
|
|
|
|
|
* Returns:
|
|
|
|
|
* CMD_SUCCESS on success, CMD_WARNING otherwise.
|
|
|
|
|
*/
|
2024-03-18 18:08:23 +01:00
|
|
|
extern int nb_cli_rpc(struct vty *vty, const char *xpath,
|
|
|
|
|
struct lyd_node **output_p);
|
lib, ripd: rework API for converted CLI commands
When editing the candidate configuration, the northbound must ensure
that either all changes made by a command are accepted or none are.
This is done to prevent inconsistent states where only parts of a
command are applied in the event any error happens.
The previous API for converted commands, the nb_cli_cfg_change()
function, required callers to pass an array containing all changes
that needed to be applied in the candidate configuration. The
problem with this API is that it was very inconvenient for complex
commands, which change different configuration options depending
on several factors. This required users to manipulate the array
of configuration changes using low-level primitives, making it
complicated to implement some commands.
To solve this problem, introduce a new API based on the two following
functions:
- nb_cli_enqueue_change()
- nb_cli_apply_changes()
The first function is used to enqueue configuration changes, one
at time. Then the nb_cli_apply_changes() function is used to apply
all the enqueued configuration changes.
To implement this, a static-sized array was allocated in the "vty"
structure, along with a counter of enqueued changes. This eliminates
the need to declare an array of configuration changes in every
converted CLI command, simplifying things quite considerably.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2018-11-26 18:30:14 +01:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Show CLI commands associated to the given YANG data node.
|
|
|
|
|
*
|
|
|
|
|
* vty
|
|
|
|
|
* The vty terminal to dump the configuration to.
|
|
|
|
|
*
|
|
|
|
|
* dnode
|
|
|
|
|
* libyang data node that should be shown in the form of CLI commands.
|
|
|
|
|
*
|
|
|
|
|
* show_defaults
|
|
|
|
|
* Specify whether to display default configuration values or not.
|
|
|
|
|
*/
|
2021-10-13 19:08:37 +02:00
|
|
|
extern void nb_cli_show_dnode_cmds(struct vty *vty,
|
|
|
|
|
const struct lyd_node *dnode,
|
2017-12-07 20:31:48 +01:00
|
|
|
bool show_defaults);
|
lib, ripd: rework API for converted CLI commands
When editing the candidate configuration, the northbound must ensure
that either all changes made by a command are accepted or none are.
This is done to prevent inconsistent states where only parts of a
command are applied in the event any error happens.
The previous API for converted commands, the nb_cli_cfg_change()
function, required callers to pass an array containing all changes
that needed to be applied in the candidate configuration. The
problem with this API is that it was very inconvenient for complex
commands, which change different configuration options depending
on several factors. This required users to manipulate the array
of configuration changes using low-level primitives, making it
complicated to implement some commands.
To solve this problem, introduce a new API based on the two following
functions:
- nb_cli_enqueue_change()
- nb_cli_apply_changes()
The first function is used to enqueue configuration changes, one
at time. Then the nb_cli_apply_changes() function is used to apply
all the enqueued configuration changes.
To implement this, a static-sized array was allocated in the "vty"
structure, along with a counter of enqueued changes. This eliminates
the need to declare an array of configuration changes in every
converted CLI command, simplifying things quite considerably.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2018-11-26 18:30:14 +01:00
|
|
|
|
lib: introduce configuration back-off timer for YANG-modeled commands
When using the default CLI mode, the northbound layer needs to create
a separate transaction to process each YANG-modeled command since
they are supposed to be applied immediately (there's no candidate
configuration nor the "commit" command like in the transactional
CLI). The problem is that configuration transactions have an overhead
associated to them, in big part because of the use of some heavy
libyang functions like `lyd_validate()` and `lyd_diff()`. As of
now this overhead is substantial and doesn't scale well when large
numbers of transactions need to be performed in sequence.
As an example, loading 50k prefix-lists using a single transaction
takes about 2 seconds on a modern CPU. Loading the same 50k
prefix-lists using 50k transactions can take more than an hour
to complete (which is unacceptable by any standard). To fix this
problem, some heavy optimization work needs to be done on libyang and
on the FRR northbound itself too (e.g. perform partial configuration
diffs whenever possible). This, however, should be a long term
effort since these optimizations shouldn't be trivial to implement
and we're far from having the performance numbers we need.
In the meanwhile, this commit introduces a simple but efficient
workaround to alleviate the issue. In short, a new back-off timer
was introduced in the CLI to monitor and detect when too many
YANG-modeled commands are being received at the same time. When
a certain threshold is reached (100 YANG-modeled commands within
one second), the northbound starts to group all subsequent commands
into a single large transaction, which allows them to be processed
much faster (e.g. seconds and not hours). It's essentially a
protection mechanism that creates dynamically-sized transactions
when necessary to prevent performance issues from happening. This
mechanism is enabled both when parsing configuration files and when
reading commands from a terminal.
The downside of this optimization is that, if several YANG-modeled
commands are grouped into the same transaction and at least one of
them fails, the whole transaction is rejected. This is undesirable
since users don't expect transactional behavior when that's not
enabled explicitly. To minimize this issue, the CLI will log all
commands that were rejected whenever that happens, to make the
user aware of what happened and have enough information to fix
the problem. Commands that fail due to parsing errors or CLI-level
validations in general are rejected separately.
Again, this proposed workaround is intended to be temporary. The
goal is to provided a quick fix to issues like #6658 while we work
on better long-term solutions.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2020-07-02 19:43:36 +02:00
|
|
|
/*
|
|
|
|
|
* Perform pending commit, if any.
|
|
|
|
|
*
|
|
|
|
|
* vty
|
|
|
|
|
* The vty context.
|
2021-05-28 21:16:18 +02:00
|
|
|
*
|
|
|
|
|
* Returns
|
|
|
|
|
* CMD_SUCCESS on success (or no pending), CMD_WARNING_CONFIG_FAILED
|
|
|
|
|
* otherwise.
|
lib: introduce configuration back-off timer for YANG-modeled commands
When using the default CLI mode, the northbound layer needs to create
a separate transaction to process each YANG-modeled command since
they are supposed to be applied immediately (there's no candidate
configuration nor the "commit" command like in the transactional
CLI). The problem is that configuration transactions have an overhead
associated to them, in big part because of the use of some heavy
libyang functions like `lyd_validate()` and `lyd_diff()`. As of
now this overhead is substantial and doesn't scale well when large
numbers of transactions need to be performed in sequence.
As an example, loading 50k prefix-lists using a single transaction
takes about 2 seconds on a modern CPU. Loading the same 50k
prefix-lists using 50k transactions can take more than an hour
to complete (which is unacceptable by any standard). To fix this
problem, some heavy optimization work needs to be done on libyang and
on the FRR northbound itself too (e.g. perform partial configuration
diffs whenever possible). This, however, should be a long term
effort since these optimizations shouldn't be trivial to implement
and we're far from having the performance numbers we need.
In the meanwhile, this commit introduces a simple but efficient
workaround to alleviate the issue. In short, a new back-off timer
was introduced in the CLI to monitor and detect when too many
YANG-modeled commands are being received at the same time. When
a certain threshold is reached (100 YANG-modeled commands within
one second), the northbound starts to group all subsequent commands
into a single large transaction, which allows them to be processed
much faster (e.g. seconds and not hours). It's essentially a
protection mechanism that creates dynamically-sized transactions
when necessary to prevent performance issues from happening. This
mechanism is enabled both when parsing configuration files and when
reading commands from a terminal.
The downside of this optimization is that, if several YANG-modeled
commands are grouped into the same transaction and at least one of
them fails, the whole transaction is rejected. This is undesirable
since users don't expect transactional behavior when that's not
enabled explicitly. To minimize this issue, the CLI will log all
commands that were rejected whenever that happens, to make the
user aware of what happened and have enough information to fix
the problem. Commands that fail due to parsing errors or CLI-level
validations in general are rejected separately.
Again, this proposed workaround is intended to be temporary. The
goal is to provided a quick fix to issues like #6658 while we work
on better long-term solutions.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2020-07-02 19:43:36 +02:00
|
|
|
*/
|
2021-05-28 21:16:18 +02:00
|
|
|
extern int nb_cli_pending_commit_check(struct vty *vty);
|
lib: introduce configuration back-off timer for YANG-modeled commands
When using the default CLI mode, the northbound layer needs to create
a separate transaction to process each YANG-modeled command since
they are supposed to be applied immediately (there's no candidate
configuration nor the "commit" command like in the transactional
CLI). The problem is that configuration transactions have an overhead
associated to them, in big part because of the use of some heavy
libyang functions like `lyd_validate()` and `lyd_diff()`. As of
now this overhead is substantial and doesn't scale well when large
numbers of transactions need to be performed in sequence.
As an example, loading 50k prefix-lists using a single transaction
takes about 2 seconds on a modern CPU. Loading the same 50k
prefix-lists using 50k transactions can take more than an hour
to complete (which is unacceptable by any standard). To fix this
problem, some heavy optimization work needs to be done on libyang and
on the FRR northbound itself too (e.g. perform partial configuration
diffs whenever possible). This, however, should be a long term
effort since these optimizations shouldn't be trivial to implement
and we're far from having the performance numbers we need.
In the meanwhile, this commit introduces a simple but efficient
workaround to alleviate the issue. In short, a new back-off timer
was introduced in the CLI to monitor and detect when too many
YANG-modeled commands are being received at the same time. When
a certain threshold is reached (100 YANG-modeled commands within
one second), the northbound starts to group all subsequent commands
into a single large transaction, which allows them to be processed
much faster (e.g. seconds and not hours). It's essentially a
protection mechanism that creates dynamically-sized transactions
when necessary to prevent performance issues from happening. This
mechanism is enabled both when parsing configuration files and when
reading commands from a terminal.
The downside of this optimization is that, if several YANG-modeled
commands are grouped into the same transaction and at least one of
them fails, the whole transaction is rejected. This is undesirable
since users don't expect transactional behavior when that's not
enabled explicitly. To minimize this issue, the CLI will log all
commands that were rejected whenever that happens, to make the
user aware of what happened and have enough information to fix
the problem. Commands that fail due to parsing errors or CLI-level
validations in general are rejected separately.
Again, this proposed workaround is intended to be temporary. The
goal is to provided a quick fix to issues like #6658 while we work
on better long-term solutions.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2020-07-02 19:43:36 +02:00
|
|
|
|
lib, ripd: rework API for converted CLI commands
When editing the candidate configuration, the northbound must ensure
that either all changes made by a command are accepted or none are.
This is done to prevent inconsistent states where only parts of a
command are applied in the event any error happens.
The previous API for converted commands, the nb_cli_cfg_change()
function, required callers to pass an array containing all changes
that needed to be applied in the candidate configuration. The
problem with this API is that it was very inconvenient for complex
commands, which change different configuration options depending
on several factors. This required users to manipulate the array
of configuration changes using low-level primitives, making it
complicated to implement some commands.
To solve this problem, introduce a new API based on the two following
functions:
- nb_cli_enqueue_change()
- nb_cli_apply_changes()
The first function is used to enqueue configuration changes, one
at time. Then the nb_cli_apply_changes() function is used to apply
all the enqueued configuration changes.
To implement this, a static-sized array was allocated in the "vty"
structure, along with a counter of enqueued changes. This eliminates
the need to declare an array of configuration changes in every
converted CLI command, simplifying things quite considerably.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2018-11-26 18:30:14 +01:00
|
|
|
/* Prototypes of internal functions. */
|
2019-10-06 06:16:47 +02:00
|
|
|
extern void nb_cli_show_config_prepare(struct nb_config *config,
|
|
|
|
|
bool with_defaults);
|
2018-12-06 23:37:05 +01:00
|
|
|
extern void nb_cli_confirmed_commit_clean(struct vty *vty);
|
|
|
|
|
extern int nb_cli_confirmed_commit_rollback(struct vty *vty);
|
2017-12-07 20:31:48 +01:00
|
|
|
extern void nb_cli_install_default(int node);
|
2023-03-07 20:14:41 +01:00
|
|
|
extern void nb_cli_init(struct event_loop *tm);
|
2017-12-07 20:31:48 +01:00
|
|
|
extern void nb_cli_terminate(void);
|
|
|
|
|
|
2019-02-07 23:10:31 +01:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2017-12-07 20:31:48 +01:00
|
|
|
#endif /* _FRR_NORTHBOUND_CLI_H_ */
|