| Client | Changes required |
|---|---|
Remote commands via the ncs command | Remote commands, such as ncs --reload, check the environment variables NCS_IPC_ADDR and NCS_IPC_PORT. |
| CLI tools | The Command Line Interface (CLI) client ncs_cli and similar commands, such as ncs_cmd and ncs_load, check the environment variables NCS_IPC_ADDR and NCS_IPC_PORT. Alternatively, many of them also support command-line options. |
| CDB and MAAPI clients | The address supplied to Cdb.connect() and Maapi.connect() must be changed. |
| Data provider API clients | The address supplied to Dp constructor socket must be changed. |
| Notification API clients | The new address must be supplied to the socket for the Nofif constructor. |
Layered CFS/RFS architecture
LSA Request Flow
Example LSA architecture
VPN network
NSO topology
NSO LSA topology
| Local Install | Install NSO for test and evaluation use. | local-install.md |
| System Install | Install NSO for production system-wide use. | system-install.md |
| Post-install Actions | Perform post-install actions after installing NSO. | post-install-actions |
| Containerized NSO | Deploy NSO using Cisco-provided container images. | containerized-nso.md |
| Dev to Prod Deployment | Deploy NSO from development to production. | development-to-production-deployment |
| Upgrade NSO | Upgrade NSO installation to a higher version. | upgrade-nso.md |
| System Management | Configure & manage your NSO deployment. | system-management |
| Package Management | Learn about NSO packages and how to use them. | package-mgmt.md |
| High Availability | Set up multiple nodes in a highly-available (HA) setup. | high-availability.md |
| AAA Infrastructure | Set up user authentication and authorization. | aaa-infrastructure.md |
| NED Administration | Administer and manage Cisco-provided NEDs. | ned-administration.md |
| Locks | Understand how transaction locks work. | locks.md |
| CDB Persistence | Select the optimal CDB persistence mode. | cdb-persistence.md |
| IPC Connection | Learn how client libraries connect to NSO. | ipc-connection.md |
| Cryptographic Keys | Encrypt and decrypt strings in NSO using crypto keys. | cryptographic-keys.md |
| Service Manager Restart | Configure the timeout period of Service Manager. | restart-strategies-for-service-manager.md |
| IPv6 on Northbound | Use IPv6 on Northbound NSO interfaces. | ipv6-on-northbound-interfaces.md |
| LSA | Learn about Layered Service Architecture. | layered-service-architecture.md |
| Local Install | Local Install is used for development, lab, and evaluation purposes. It unpacks all the application components, including docs and examples. It can be used by the engineer to run multiple, unrelated, instances of NSO for different labs and demos on a single workstation. | local-install.md |
| System Install | System Install is used when installing NSO for a centralized, always-on, production-grade, system-wide deployment. It is configured as a system daemon that would start and end with the underlying operating system. The default users of admin and operator are not included and the file structure is more distributed. | system-install.md |
| Intended Use | Develop NSO Packages | Build NSO Packages | Run NSO | NSO Install Type |
|---|---|---|---|---|
| Development Host |  |  | | None or Local Install |
| Build Image | | | | System Install |
| Production Image | | | | System Install |
-
-
-
-{% hint style="info" %}
-**Loading the Packages**
-
-* Loading the packages by mounting the default load path `/nso/run` as a volume is preferred. You can also load the packages by copying them manually into the `/nso/run/packages` directory in the container. During development, a bind mount of the package directory on the host machine makes it easy to update packages in NSO by simply changing the packages on the host.
-* The default load path is configured in the `ncs.conf` file as `$NCS_RUN_DIR/packages`, where `$NCS_RUN_DIR` expands to `/nso/run` in the container. To find the load path, check the `ncs.conf` file in the `/etc/ncs/` directory.
-
- ```xml
- Examples: Running the Image with and without Named Volumes
- -The following examples show how to run the image with and without named volumes. - -**Running without a named volume**: This is the minimal way of running the image but does not provide any persistence when the container is destroyed. - -```bash -docker run -itd --name cisco-nso \ --p 8888:8888 \ --e ADMIN_USERNAME=admin\ --e ADMIN_PASSWORD=admin\ -cisco-nso-prod -``` - -**Running with a single named volume**: This way provides persistence for the NSO mount point with a `NSO-vol` volume. Logs, however, are not persistent. - -```bash - -docker run -itd --name cisco-nso \ --v NSO-vol:/nso \ --p 8888:8888 \ --e ADMIN_USERNAME=admin\ --e ADMIN_PASSWORD=admin\ -cisco-nso-prod -``` - -\ -**Running with two named volumes**: This way provides full persistence for both the NSO and the log mount points. - -```bash -docker run -itd --name cisco-nso \ --v NSO-vol:/nso \ --v NSO-log-vol:/log \ --p 8888:8888 \ --e ADMIN_USERNAME=admin\ --e ADMIN_PASSWORD=admin\ -cisco-nso-prod -``` - -
-
-
-
-#### **Steps**
-
-Follow the steps below to run the images using Docker Compose:
-
-1. Start the Build container. This starts the services in the Compose file with the profile `build`.
-
- ```bash
- docker compose --profile build up -d
- ```
-2. Copy the packages from the `netsim-sshkey` example and compile them in the NSO Build container. The easiest way to do this is by using the `docker exec` command, which gives more control over what to build and the order of it. You can also do this with a script to make it easier and less verbose. Normally you populate the package directory from the host. Here, we use the packages from an example.
-
- ```bash
- docker exec -it build-nso-pkgs sh -c 'cp -r ${NCS_DIR}/examples.ncs/getting-started \
- /netsim-sshkey/packages ${NCS_RUN_DIR}'
-
- docker exec -it build-nso-pkgs sh -c 'for f in ${NCS_RUN_DIR}/packages/*/src; \
- do make -C "$f" all || exit 1; done'
- ```
-3. Start the netsim container. This outputs the generated `init.xml` and `ncs.conf` files to the NSO Production container. The `--wait` flag instructs to wait until the health check returns healthy.
-
- ```bash
- docker compose --profile example up --wait
- ```
-4. Start the NSO Production container.
-
- ```bash
- docker compose --profile prod up --wait
- ```
-
- \
- At this point, NSO is ready to run the service example to configure the netsim device(s). A bash script (`demo.sh`) that runs the above steps and showcases the `netsim-sshkey` example is given below:
-
- ```
- #!/bin/bash
- set -eu # Abort the script if a command returns with a non-zero exit code or if
- # a variable name is dereferenced when the variable hasn't been set
- GREEN='\033[0;32m'
- PURPLE='\033[0;35m'
- NC='\033[0m' # No Color
-
- printf "${GREEN}##### Reset the container setup\n${NC}";
- docker compose --profile build down
- docker compose --profile example down -v
- docker compose --profile prod down -v
- rm -rf ./packages/NSO-1/* ./log/NSO-1/*
-
- printf "${GREEN}##### Start the build container used for building the NSO NED
- and service packages\n${NC}"
- docker compose --profile build up -d
-
- printf "${GREEN}##### Get the packages\n${NC}"
- printf "${PURPLE}##### NOTE: Normally you populate the package directory from the host.
- Here, we use packages from an NSO example\n${NC}"
- docker exec -it build-nso-pkgs sh -c 'cp -r
- ${NCS_DIR}/examples.ncs/getting-started/netsim-sshkey/packages ${NCS_RUN_DIR}'
-
- printf "${GREEN}##### Build the packages\n${NC}"
- docker exec -it build-nso-pkgs sh -c 'for f in ${NCS_RUN_DIR}/packages/*/src;
- do make -C "$f" all || exit 1; done'
-
- printf "${GREEN}##### Start the simulated device container and setup the example\n${NC}"
- docker compose --profile example up --wait
-
- printf "${GREEN}##### Start the NSO prod container\n${NC}"
- docker compose --profile prod up --wait
-
- printf "${GREEN}##### Showcase the netsim-sshkey example from NSO on the prod container\n${NC}"
- if [[ $# -eq 0 ]] ; then # Ask for input only if no argument was passed to this script
- printf "${PURPLE}##### Press any key to continue or ctrl-c to exit\n${NC}"
- read -n 1 -s -r
- fi
- docker exec -it nso1 sh -c 'sed -i.orig -e "s/make/#make/"
- ${NCS_DIR}/examples.ncs/getting-started/netsim-sshkey/showcase.sh'
- docker exec -it nso1 sh -c 'cd ${NCS_RUN_DIR};
- ${NCS_DIR}/examples.ncs/getting-started/netsim-sshkey/showcase.sh 1'
- ```
-
-### Upgrading NSO using Docker Compose
-
-This example describes how to upgrade NSO when using Docker Compose.
-
-#### **Upgrade to a New Minor or Major Version**
-
-To upgrade to a new minor or major version, for example, from 6.3 to 6.4, follow the steps below:
-
-1. Change the image version in the Compose file to the new version, here 6.4.
-2. Run the `docker compose up --profile build -d` command to start the Build container with the new image.
-3. Compile the packages using the Build container.
-
- ```bash
- docker exec -it build-nso-pkgs sh -c 'for f in
- ${NCS_RUN_DIR}/packages/*/src;do make -C "$f" all || exit 1; done'
- ```
-4. Run the `docker compose up --profile prod --wait` command to start the Production container with the new packages that were just compiled.
-
-#### **Upgrade to a New Maintenance Version**
-
-To upgrade to a new maintenance release version, for example, 6.4.1, follow the steps below:
-
-1. Change the image version in the Compose file to the new version, here 6.4.1.
-2. Run the `docker compose up --profile prod --wait` command.
-
- Upgrading in this way does not require a recompile. Docker detects changes and upgrades the image in the container to the new version.
diff --git a/administration/installation-and-deployment/deployment/deployment-example.md b/administration/installation-and-deployment/deployment/deployment-example.md
deleted file mode 100644
index 5b089dce..00000000
--- a/administration/installation-and-deployment/deployment/deployment-example.md
+++ /dev/null
@@ -1,348 +0,0 @@
----
-description: Understand NSO deployment with an example setup.
----
-
-# Deployment Example
-
-This section shows examples of a typical deployment for a highly available (HA) setup. A reference to an example implementation of the `tailf-hcc` layer-2 upgrade deployment scenario described here, check the NSO example set under [examples.ncs/high-availability/hcc](https://github.com/NSO-developer/nso-examples/tree/6.6/high-availability/hcc). The example covers the following topics:
-
-* Installation of NSO on all nodes in an HA setup
-* Initial configuration of NSO on all nodes
-* HA failover
-* Upgrading NSO on all nodes in the HA cluster
-* Upgrading NSO packages on all nodes in the HA cluster
-
-The deployment examples use both the legacy rule-based and recommended HA Raft setup. See [High Availability](../../management/high-availability.md) for HA details. The HA Raft deployment consists of three nodes running NSO and a node managing them, while the rule-based HA deployment uses only two nodes.
-
-Based on the Raft consensus algorithm, the HA Raft version provides the best fault tolerance, performance, and security and is therefore recommended.
-
-For the HA Raft setup, the NSO nodes `paris.fra`, `london.eng`, and `berlin.ger` nodes make up a cluster of one leader and two followers.
-
-Explanation of the Docker Compose File
- -A description of noteworthy Compose file items is given below. - -* **`profiles`**: Profiles can be used to group containers in a Compose file, and they work perfectly for the Production, Build, and netsim containers. By adding multiple containers on the same machine (as a developer normally would), you can easily start the Production, Build, and netsim containers using their respective profiles (`prod`, `build`, and `example`). -* **The command used in the netsim example**: Creates a directory called `/netsim` where the netsims will be set up, then starts the netsims, followed by generating two `init.xml` files and editing the `ncs.conf` file for the Production container. Finally, it keeps the container running. If you want this to be more elegant, you need a netsim container image with a script in it that is well-documented. -* **`volumes`**: The Production and Build images are configured intentionally to have the same bind mount with `/path/to/packages/NSO-1` as the source and `/nso/run/packages` as the target. The Production Image mounts both the `/log` and `/nso` directories in the container. The `/log` directory is simply a bind mount, while the `/nso` directory is an actual volume. - - \ - Named volumes are recommended over bind mounts as described by the Docker Volumes documentation. The NSO `/run` directory should therefore be mounted as a named volume. However, you can make the `/run` directory a bind mount as well. - - The Compose file, typically named `docker-compose.yaml`, declares a volume called `NSO-1-rvol`. This is a named volume and will be created automatically by Compose. You can create this volume externally, at which point this volume must be declared as external. If the external volume doesn't exist, the container will not start. - - \ - The `example` netsim container will mount the network element NED in the packages directory. This package should be compiled. Note that the `NSO-1-rvol` volume is used by the `example` container to share the generated `init.xml` and `ncs.conf` files with the NSO Production container. -* **`healthcheck`**: The image comes with its own health check (similar to the one shown here in Compose), and this is how you configure it yourself. The health check for the netsim `example` container checks if the `ncs.conf` file has been generated, and the first Netsim instance started in the container. You could, in theory, start more netsims inside the container. - -
The HA Raft Deployment Network
The Rule-Based HA Deployment Network
The Development Host Topology
The Deployment Container Topology
-
-
-
-Primary Requirements
- -Primary requirements to do a Local Install include: - -* A system running Linux or macOS on either the `x86_64` or `ARM64` architecture for development. For [FIPS](https://www.nist.gov/itl/publications-0/federal-information-processing-standards-fips) mode, OS FIPS compliance may be required depending on your specific requirements. -* GNU libc 2.24 or higher. -* Java JRE 17 or higher. Used by Cisco Smart Licensing. -* Required and included with many Linux/macOS distributions: - * `tar` command. Unpack the installer. - * `gzip` command. Unpack the installer. - * `ssh-keygen` command. Generate SSH host key. - * `openssl` command. Generate self-signed certificates for HTTPS. - * `find` command. Used to find out if all required libraries are available. - * `which` command. Used by the NSO package manager. - * `libpam.so.0`. Pluggable Authentication Module library. - * `libexpat.so.1`. EXtensible Markup Language parsing library. - * `libz.so.1` version 1.2.7.1 or higher. Data compression library. - -
-
-
-
-Additional Requirements
- -Additional requirements to, for example, build and run NSO examples/services include: - -* Java JDK 17 or higher. -* Ant 1.9.8 or higher. -* Python 3.10 or higher. -* Python Setuptools is required to build the Python API. -* Often installed using the Python package installer pip: - * Python Paramiko 2.2 or higher. To use netconf-console. - * Python requests. Used by the RESTCONF demo scripts. -* `xsltproc` command. Used by the `support/ned-make-package-meta-data` command to generate the `package-meta-data.xml` file. -* One of the following web browsers is required for NSO GUI capabilities. The version must be supported by the vendor at the time of release. - * Safari - * Mozilla Firefox - * Microsoft Edge - * Google Chrome -* OpenSSH client applications. For example, the `ssh` and `scp` commands. - -
-
-
-
-### Step 2 - Download the Installer and NEDs
-
-To download the Cisco NSO installer and example NEDs:
-
-1. Go to the Cisco's official [Software Download](https://software.cisco.com/download/home) site.
-2. Search for the product "Network Services Orchestrator" and select the desired version.
-3. There are two versions of the NSO installer, i.e. for macOS and Linux systems. Download the desired installer.
-
-FIPS Mode Entropy Requirements
- -The following applies if you are running a container-based setup of your FIPS install: - -In containerized environments (e.g., Docker) that run on older Linux kernels (e.g., Ubuntu 18.04), `/dev/random` may block if the system’s entropy pool is low. This can lead to delays or hangs in FIPS mode, as cryptographic operations require high-quality randomness. - -To avoid this: - -* Prefer newer kernels (e.g., Ubuntu 22.04 or later), where entropy handling is improved to mitigate the issue. -* Or, install an entropy daemon like Haveged on the Docker host to help maintain sufficient entropy. - -Check available entropy on the host system with: - -```bash -cat /proc/sys/kernel/random/entropy_avail -``` - -A value of 256 or higher is generally considered safe. Reference: [Oracle blog post](https://blogs.oracle.com/linux/post/entropyavail-256-is-good-enough-for-everyone). - -
-
-
-
-### Step 3 - Unpack the Installer
-
-If your downloaded file is a `signed.bin` file, it means that it has been digitally signed by Cisco, and upon execution, you will verify the signature and unpack the `installer.bin`.
-
-If you only have `installer.bin`, skip to the next step.
-
-To unpack the installer:
-
-1. In the terminal, list the binaries in the directory where you downloaded the installer, for example:
-
- ```bash
- cd ~/Downloads
- ls -l nso*.bin
- -rw-r--r--@ 1 user staff 199M Dec 15 11:45 nso-6.0.darwin.x86_64.installer.bin
- -rw-r--r--@ 1 user staff 199M Dec 15 11:45 nso-6.0.darwin.x86_64.signed.bin
- ```
-2. Use the `sh` command to run the `signed.bin` to verify the certificate and extract the installer binary and other files. An example output is shown below.
-
- ```bash
- sh nso-6.0.darwin.x86_64.signed.bin
- # Output
- Unpacking...
- Verifying signature...
- Downloading CA certificate from http://www.cisco.com/security/pki/certs/crcam2.cer ...
- Successfully downloaded and verified crcam2.cer.
- Downloading SubCA certificate from http://www.cisco.com/security/pki/certs/innerspace.cer ...
- Successfully downloaded and verified innerspace.cer.
- Successfully verified root, subca and end-entity certificate chain.
- Successfully fetched a public key from tailf.cer.
- Successfully verified the signature of nso-6.0.darwin.x86_64.installer.bin using tailf.cer
- ```
-3. List the files to check if extraction was successful.
-
- ```bash
- ls -l
- # Output
- -rw-r--r-- 1 user staff 1.8K Nov 29 06:05 README.signature
- -rw-r--r-- 1 user staff 12K Nov 29 06:05 cisco_x509_verify_release.py
- -rwxr-xr-x 1 user staff 199M Nov 29 05:55 nso-6.0.darwin.x86_64.installer.bin
- -rw-r--r-- 1 user staff 256B Nov 29 06:05 nso-6.0.darwin.x86_64.installer.bin.signature
- -rwxr-xr-x@ 1 user staff 199M Dec 15 11:45 nso-6.0.darwin.x86_64.signed.bin
- -rw-r--r-- 1 user staff 1.4K Nov 29 06:05 tailf.cer
- ```
-
-Identifying the Installer
- -You need to know your system specifications (Operating System and CPU architecture) in order to choose the appropriate NSO installer. - -NSO is delivered as an OS/CPU-specific signed self-extractable archive. The signed archive file has the pattern `nso-VERSION.OS.ARCH.signed.bin` that after signature verification extracts the `nso-VERSION.OS.ARCH.installer.bin` archive file, where: - -* `VERSION` is the NSO version to install. -* `OS` is the Operating System (`linux` for all Linux distributions and `darwin` for macOS). -* `ARCH` is the CPU architecture, for example`x86_64`. - -
-
-.
-The first time --system-install is used, the ConfigDir,
-RunDir, and LogDir directories are also created and
-populated for config files, run-time state files, and log files,
-respectively, and an init script for start of NCS at system boot
-and user profile scripts are installed. Defaults are:
-
-InstallDir - /opt/ncs
-ConfigDir - /etc/ncs
-RunDir - /var/opt/ncs
-LogDir - /var/log/ncs
-
-By default, the system install will run NCS as the root user.
-If the --run-as-user option is given, the system install will
-instead run NCS as the given user. The user will be created if
-it does not already exist.
-If the --non-interactive option is given, the installer will
-proceed with potentially disruptive changes (e.g. modifying or
-removing existing files) without asking for confirmation.
-```
-
-
-
-### Step 4 - Run the Installer
-
-Local Install of NSO software is performed in a single user-specified directory, for example in your `$HOME` directory.
-
-{% hint style="success" %}
-It is always recommended to install NSO in a directory named as the version of the release, for example, if the version being installed is `6.1`, the directory should be `~/nso-6.1`.
-{% endhint %}
-
-To run the installer:
-
-1. Navigate to your Install Directory.
-2. Run the command given below to install NSO in your Install Directory. The `--local-install` parameter is optional. At this point, you can choose to install NSO in standard mode or in FIPS mode.
-
-{% tabs %}
-{% tab title="Standard Local Install" %}
-The standard mode is the regular NSO install and is suitable for most installations. FIPS is disabled in this mode.
-
-For standard NSO install, run the installer as below:
-
-```bash
-$ sh nso-VERSION.OS.ARCH.installer.bin $HOME/ncs-VERSION --local-install
-```
-
-An example output is shown below:
-
-{% code title="Example: Standard Local Install" %}
-```bash
-sh nso-6.0.darwin.x86_64.installer.bin --local-install ~/nso-6.0
-
-# Output
-INFO Using temporary directory /var/folders/90/n5sbctr922336_
-0jrzhb54400000gn/T//ncs_installer.93831 to stage NCS installation bundle
-INFO Unpacked ncs-6.0 in /Users/user/nso-6.0
-INFO Found and unpacked corresponding DOCUMENTATION_PACKAGE
-INFO Found and unpacked corresponding EXAMPLE_PACKAGE
-INFO Found and unpacked corresponding JAVA_PACKAGE
-INFO Generating default SSH hostkey (this may take some time)
-INFO SSH hostkey generated
-INFO Environment set-up generated in /Users/user/nso-6.0/ncsrc
-INFO NSO installation script finished
-INFO Found and unpacked corresponding NETSIM_PACKAGE
-INFO NCS installation complete
-```
-{% endcode %}
-{% endtab %}
-
-{% tab title="FIPS Local Install" %}
-FIPS mode creates a FIPS-compliant NSO install.
-
-FIPS mode should only be used for deployments that are subject to strict compliance regulations as the cryptographic functions are then confined to the CiscoSSL FIPS 140-3 module library.
-
-For FIPS-compliant NSO install, run the installer with the additional `--fips-install` flag. Afterwards, verify FIPS in `ncs.conf`.
-
-```bash
-$ sh nso-VERSION.OS.ARCH.installer.bin $HOME/ncs-VERSION --local-install --fips-install
-```
-
-{% hint style="info" %}
-**NSO Configuration for FIPS**
-
-Note the following as part of FIPS-specific configuration/install:
-
-1. The `ncs.conf` file is automatically configured to enable FIPS by setting the following flag:
-
-```xml
-Description of Unpacked Files
- -The following contents are unpacked: - -* `nso-VERSION.OS.ARCH.installer.bin`: The NSO installer. -* `nso-VERSION.OS.ARCH.installer.bin.signature`: Signature generated for the NSO image. -* `tailf.cer`: An enclosed Cisco signed x.509 end-entity certificate containing the public key that is used to verify the signature. -* `README.signature`: File with further details on the unpacked content and steps on how to run the signature verification program. To manually verify the signature, refer to the steps in this file. -* `cisco_x509_verify_release.py`: Python program that can be used to verify the 3-tier x.509 certificate chain and signature. -* Multiple `.tar.gz` files: Bundled packages, extending the base NSO functionality. -* Multiple `.tar.gz.signature` files: Digital signatures for the bundled packages. - -Since NSO version 6.3, a few additional NSO packages are included. They contain the following platform tools: - -* HCC -* Observability Exporter - -- Phased Provisioning -- Resource Manager - -For platform tools documentation, refer to the individual package's `README` file or to the [online documentation](https://nso-docs.cisco.com/resources). - -**NED packages** - -The NED packages that are available with the NSO installation are NetSim-based example NEDs. These NEDs are used for NSO examples only. - -Fetch the latest production-grade NEDs from [Cisco Software Download](https://software.cisco.com/download/home) using the URLs provided on your NED license certificates. - -**Manual pages** - -The installation program unpacks the NSO manual pages from the documentation archive in `$NCS_DIR/man`. `ncsrc` makes an addition to `$MANPATH`, allowing you to use the `man` command to view them. The manual pages are available in PDF format and from the online documentation located on [NCS man-pages, Volume 1](../../resources/man/README.md) in Manual Pages. - -Following is a list of a few of the installed manual pages: - -* `ncs(1)`: Command to start and control the NSO daemon. -* `ncsc(1)`: NSO Yang compiler. -* `ncs_cli(1)`: Frontend to the NSO CLI engine. -* `ncs-netsim(1)`: Command to create and manipulate a simulated network. -* `ncs-setup(1)`: Command to create an initial NSO setup. -* `ncs.conf`: NSO daemon configuration file format. - -For example, to view the manual page describing the NSO configuration file, you should type: - -```bash -$ man ncs.conf -``` - -Apart from the manual pages, extensive information about command-line options can be obtained by running `ncs` and `ncsc` with the `--help` (abbreviated `-h`) flag. - -```bash -$ ncs --help -``` - -```bash -$ ncsc --help -``` - -**Installer help** - -Run the `sh nso-VERSION.darwin.x86_64.installer.bin --help` command to view additional help on running binaries. More details can be found in the [ncs-installer(1)](../../resources/man/ncs-installer.1.md) Manual Page included with NSO. - -Notice the two options for `--local-install` or `--system-install`. An example output is shown below. - -```bash -sh nso-6.0.darwin.x86_64.installer.bin --help - -# Output -This is the NCS installation script. -Usage: ./nso-6.0.darwin.x86_64.installer.bin [--local-install] LocalInstallDir -Installs NCS in the LocalInstallDir directory only. -This is convenient for test and development purposes. -Usage: ./nso-6.0.darwin.x86_64.installer.bin --system-install -[--install-dir InstallDir] -[--config-dir ConfigDir] [--run-dir RunDir] [--log-dir LogDir] -[--run-as-user User] [--keep-ncs-setup] [--non-interactive] - -Does a system install of NCS, suitable for deployment. -Static files are installed in InstallDir/ncs-
-
-
-
-{% hint style="warning" %}
-The `ncs-setup` command creates an `ncs.conf` file that uses predefined encryption keys for easier migration of data across installations. It is not suitable for cases where data confidentiality is required, such as a production deployment. See [Cryptographic Keys](../advanced-topics/cryptographic-keys.md) for ways to generate suitable keys.
-{% endhint %}
-
-### Step 7 - Generate License Registration Token
-
-To conclude the NSO installation, a license registration token must be created using a (CSSM) account. This is because NSO uses Cisco Smart Licensing, as described in the [Cisco Smart Licensing](../management/system-management/cisco-smart-licensing.md) to make it easy to deploy and manage NSO license entitlements. Login credentials to the [Cisco Smart Software Manager](https://www.cisco.com/c/en/us/buy/smart-accounts/software-manager.html) (CSSM) account are provided by your Cisco contact and detailed instructions on how to [create a registration token](../management/system-management/cisco-smart-licensing.md#d5e2927) can be found in the Cisco Smart Licensing. General licensing information covering licensing models, how licensing works, usage compliance, etc., is covered in the [Cisco Software Licensing Guide](https://www.cisco.com/c/en/us/buy/licensing/licensing-guide.html).
-
-To generate a license registration token:
-
-1. When you have a token, start a Cisco CLI towards NSO and enter the token, for example:
-
- ```bash
- $ ncs_cli -Cu admin
- admin@ncs# license smart register idtoken YzIzMDM3MTgtZTRkNC00YjkxLTk2ODQt
- OGEzMTM3OTg5MG
- Registration process in progress.
- Use the 'show license status' command to check the progress and result.
- ```
-
- \
- Upon successful registration, NSO automatically requests a license entitlement for its own instance and for the number of devices it orchestrates and their NED types. If development mode has been enabled, only development entitlement for the NSO instance itself is requested.
-2. Inspect the requested entitlements using the command `show license all` (or by inspecting the NSO daemon log). An example output is shown below.
-
- ```bash
- admin@ncs# show license all
- ...
- Runtime vs. Installation Directory
- -A common misunderstanding is that there exists a dependency between the Runtime Directory and the Installation Directory. This is not true. For example, say that you have two NSO local installations `path/to/nso-6.4` and `path/to/nso-6.4.1`. The following sequence runs `nso-6.4` but uses an example and configuration from `nso-6.4.1`. - -```bash - $ cd path/to/nso-6.4 - $ . ncsrc - $ cd path/to/nso-6.4.1/examples.ncs/service-management/datacenter-qinq - $ ncs -``` - -Since the Runtime Directory is self-contained, this is also the way to move between examples. And since the Runtime Directory is self-contained including the database files, you can compress a complete directory and distribute it. Unpacking that directory and starting NSO from there gives an exact copy of all instance data. - -```bash - $ cd path/to/nso-6.4.1/examples.ncs/service-management/datacenter-qinq - $ ncs - $ ncs --stop - $ cd path/to/nso-6.4.1/examples.ncs/device-management/simulated-cisco-ios - $ ncs - $ ncs --stop -``` - -
-
- 13-Apr-2016::13:22:29.178 miosaterm confd[16260]:
- Starting the NCS Smart Licensing Java VM
- 13-Apr-2016::13:22:34.737 miosaterm confd[16260]:
-Smart Licensing evaluation time remaining: 90d 0h 0m 0s
-...
- 13-Apr-2016::13:22:34.737 miosaterm confd[16260]:
- Smart Licensing evaluation time remaining: 89d 23h 0m 0s
-...
-```
-
-
-
-Evaluation Period
- -If no registration token is provided, NSO enters a 90-day evaluation period, and the remaining evaluation time is recorded hourly in the NSO daemon log: - -``` -... -
-
-
-
-Communication Send Error
- -During upgrades, if you experience the 'Communication Send Error' with license registration, restart the Smart Agent. - -
-
-` to point to the satellite.
-
-Another option when direct access is not desired is to configure an HTTP or HTTPS proxy, e.g., `smart-license smart-agent proxy url https://127.0.0.1:8080`. If you plan to do this, take the note below regarding ignored CLI configurations into account:
-
-If `ncs.conf` contains a configuration for any of the java-executable, java-options, override-url/url, or proxy/url under the configure path `/ncs-config/smart-license/smart-agent/`, then any corresponding configuration done via the CLI is ignored.
-
-
-
-If You are Unable to Access Cisco Smart Software Manager
- -In a situation where the NSO instance has no direct access to the Cisco Smart Software Manager, one option is the [Cisco Smart Software Manager Satellite](https://software.cisco.com/software/csws/ws/platform/home) which can be installed to manage software licenses on the premises. Install the satellite and use the command `call-home destination address http
-
-
-
-License Registration in High Availability (HA) Mode
- -When configuring NSO in HA mode, the license registration token must be provided to the CLI running on the primary node. Read more about HA and node types in NSO [High Availability](../management/high-availability.md). - -
-
- 21-Apr-2016::11:29:18.022 miosaterm confd[8226]:
- Smart Licensing Global Notification:
- type = "notifyRegisterSuccess"
-```
-
-
-
-Licensing Log
- -Licensing activities are also logged in the NSO daemon log as described in [Monitoring NSO](../management/system-management/#d5e7876). For example, a successful token registration results in the following log entry: - -``` -
-
-
-
-## Local Install FAQs
-
-Frequently Asked Questions (FAQs) about Local Install.
-
-Check Registration Status
- -To check the registration status, use the command `show license status` An example output is shown below. - -```bash -admin@ncs# show license status -Smart Licensing is ENABLED - -Registration: -Status: REGISTERED -Smart Account: Network Services Orchestrator -Virtual Account: Default -Export-Controlled Functionality: Allowed -Initial Registration: SUCCEEDED on Apr 21 09:29:11 2016 UTC -Last Renewal Attempt: SUCCEEDED on Apr 21 09:29:16 2016 UTC -Next Renewal Attempt: Oct 18 09:29:16 2016 UTC -Registration Expires: Apr 21 09:26:13 2017 UTC -Export-Controlled Functionality: Allowed - -License Authorization: -License Authorization: -Status: IN COMPLIANCE on Apr 21 09:29:18 2016 UTC -Last Communication Attempt: SUCCEEDED on Apr 21 09:26:30 2016 UTC -Next Communication Attempt: Apr 21 21:29:32 2016 UTC -Communication Deadline: Apr 21 09:26:13 2017 UTC -``` - -
-
-
-
-Is there a dependency between the NSO Installation Directory and Runtime Directory?
- -No, there is no such dependency. - -
-
-Do you need to source the
-
-Yes.
-
-
-
-Do you need to source the ncsrc file before starting NSO?
-
-Yes.
-
-
-
-
-
-Can you start NSO from a directory that is not an NSO runtime directory?
- -No. To start NSO, you need to point to the run directory. - -
-
-
-
-Can you stop NSO from a directory that is not an NSO runtime directory?
- -Yes. - -
-
-
-
-***
-
-**Next Steps**
-
-{% content-ref url="post-install-actions/explore-the-installation.md" %}
-[explore-the-installation.md](post-install-actions/explore-the-installation.md)
-{% endcontent-ref %}
diff --git a/administration/installation-and-deployment/post-install-actions/README.md b/administration/installation-and-deployment/post-install-actions/README.md
deleted file mode 100644
index aa3a4d4e..00000000
--- a/administration/installation-and-deployment/post-install-actions/README.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-description: Perform actions and activities possible after installing NSO.
----
-
-# Post-Install Actions
-
-The following actions are possible after installing NSO.
-
-## After Local Install
-
-{% content-ref url="explore-the-installation.md" %}
-[explore-the-installation.md](explore-the-installation.md)
-{% endcontent-ref %}
-
-{% content-ref url="start-stop-nso.md" %}
-[start-stop-nso.md](start-stop-nso.md)
-{% endcontent-ref %}
-
-{% content-ref url="create-nso-instance.md" %}
-[create-nso-instance.md](create-nso-instance.md)
-{% endcontent-ref %}
-
-{% content-ref url="enable-development-mode.md" %}
-[enable-development-mode.md](enable-development-mode.md)
-{% endcontent-ref %}
-
-{% content-ref url="running-nso-examples.md" %}
-[running-nso-examples.md](running-nso-examples.md)
-{% endcontent-ref %}
-
-{% content-ref url="migrate-to-system-install.md" %}
-[migrate-to-system-install.md](migrate-to-system-install.md)
-{% endcontent-ref %}
-
-{% content-ref url="uninstall-local-install.md" %}
-[uninstall-local-install.md](uninstall-local-install.md)
-{% endcontent-ref %}
-
-## After System Install
-
-{% content-ref url="modify-examples-for-system-install.md" %}
-[modify-examples-for-system-install.md](modify-examples-for-system-install.md)
-{% endcontent-ref %}
-
-{% content-ref url="uninstall-system-install.md" %}
-[uninstall-system-install.md](uninstall-system-install.md)
-{% endcontent-ref %}
diff --git a/administration/installation-and-deployment/post-install-actions/create-nso-instance.md b/administration/installation-and-deployment/post-install-actions/create-nso-instance.md
deleted file mode 100644
index 8c779b3d..00000000
--- a/administration/installation-and-deployment/post-install-actions/create-nso-instance.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-description: Create a new NSO instance for Local Install.
----
-
-# Create NSO Instance
-
-{% hint style="warning" %}
-Applies to Local Install.
-{% endhint %}
-
-One of the included scripts with an NSO installation is the `ncs-setup`, which makes it very easy to create instances of NSO from a Local Install. You can look at the `--help` or [ncs-setup(1)](../../../resources/man/ncs-setup.1.md) in Manual Pages for more details, but the two options we need to know are:
-
-* `--dest` defines the directory where you want to set up NSO. if the directory does not exist, it will be created.
-* `--package` defines the NEDs that you want to have installed. You can specify this option multiple times.
-
-{% hint style="info" %}
-NCS is the original name of the NSO product. Therefore, many of the commands and application features are prefaced with `ncs`. You can think of NCS as another name for NSO.
-{% endhint %}
-
-To create an NSO instance:
-
-1. Run the command to set up an NSO instance in the current directory with the IOS, NX-OS, IOS-XR and ASA NEDs. You only need one NED per platform that you want NSO to manage, even if you may have multiple versions in your installer `neds` directory.
-
- \
- Use the name of the NED folder in `${NCS_DIR}/packages/neds` for the latest NED version that you have installed for the target platform. Use the tab key to complete the path after you start typing (alternatively, copy and paste). Verify that the NED versions below match what is currently on the sandbox to avoid a syntax error. See the example below.
-
- ```bash
- ncs-setup --package ~/nso-6.0/packages/neds/cisco-ios-cli-6.44 \
- --package ~/nso-6.0/packages/neds/cisco-nx-cli-5.15 \
- --package ~/nso-6.0/packages/neds/cisco-iosxr-cli-7.20 \
- --package ~/nso-6.0/packages/neds/cisco-asa-cli-6.8 \
- --dest nso-instance
- ```
-2. Check the `nso-instance` directory. Notice that several new files and folders are created.
-
- ```bash
- $ ls nso-instance/
- logs ncs-cdb ncs.conf packages README.ncs scripts state
- $ ls -l nso-instance/packages/
- total 0
- lrwxrwxrwx 1 user docker 51 Mar 19 12:44 cisco-asa-cli-6.8 ->
- /home/user/nso-6.0/packages/neds/cisco-asa-cli-6.8
-
- lrwxrwxrwx 1 user docker 52 Mar 19 12:44 cisco-ios-cli-6.44 ->
- /home/user/nso-6.0/packages/neds/cisco-ios-cli-6.44
-
- lrwxrwxrwx 1 user docker 54 Mar 19 12:44 cisco-iosxr-cli-7.20 ->
- /home/user/nso-6.0/packages/neds/cisco-iosxr-cli-7.20
-
- lrwxrwxrwx 1 user docker 51 Mar 19 12:44 cisco-nx-cli-5.15 ->
- /home/user/nso-6.0/packages/neds/cisco-nx-cli-5.15
- $
- ```
-
- Following is a description of the important files and folders:
-
- * `ncs.conf` is the NSO application configuration file and is used to customize aspects of the NSO instance (for example, to change ports, enable/disable features, and so on.) See [ncs.conf(5)](../../../resources/man/ncs.conf.5.md) in Manual Pages for information.
- * `packages/` is the directory that has symlinks to the NEDs that we referenced in the `--package` arguments at the time of setup. See [NSO Packages](../../../development/core-concepts/packages.md) in Development for more information.
- * `logs/` is the directory that contains all the logs from NSO. This directory is useful for troubleshooting.
-3. Start the NSO instance by navigating to the `nso-instance` directory and typing the `ncs` command. You must be situated in the `nso-instance` directory each time you want to start or stop NSO. If you have multiple instances, you need to navigate to each one and use the `ncs` command to start or stop each one.
-4. Verify that NSO is running by using the `ncs --status | grep status` command.
-
- ```bash
- $ ncs --status | grep status
- status: started
- db=running id=31 priority=1 path=/ncs:devices/device/live-status-protocol/device-type
- ```
-5. Add Netsim or lab devices using the command `ncs-netsim -h`.
diff --git a/administration/installation-and-deployment/post-install-actions/enable-development-mode.md b/administration/installation-and-deployment/post-install-actions/enable-development-mode.md
deleted file mode 100644
index d4909f59..00000000
--- a/administration/installation-and-deployment/post-install-actions/enable-development-mode.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-description: Enable your NSO instance for development purposes.
----
-
-# Enable Development Mode
-
-{% hint style="warning" %}
-Applies to Local Install
-{% endhint %}
-
-If you intend to use your NSO instance for development purposes, enable the development mode using the command `license smart development enable`.
diff --git a/administration/installation-and-deployment/post-install-actions/explore-the-installation.md b/administration/installation-and-deployment/post-install-actions/explore-the-installation.md
deleted file mode 100644
index 11adb134..00000000
--- a/administration/installation-and-deployment/post-install-actions/explore-the-installation.md
+++ /dev/null
@@ -1,165 +0,0 @@
----
-description: Explore NSO contents after finishing the installation.
----
-
-# Explore the Installation
-
-{% hint style="warning" %}
-Applies to Local Install.
-{% endhint %}
-
-Before starting NSO, it is recommended to explore the installation contents.
-
-Navigate to the newly created Installation Directory, for example:
-
-```bash
-cd ~/nso-6.0
-```
-
-## Contents of the Installation Directory
-
-The installation directory includes the following contents:
-
-* [Documentation](explore-the-installation.md#d5e552)
-* [Examples](explore-the-installation.md#d5e560)
-* [Network Element Drivers](explore-the-installation.md#d5e564)
-* [Shell scripts](explore-the-installation.md#d5e604)
-
-### Documentation
-
-Along with the binaries, NSO installs a full set of documentation available in the `doc/` folder in the Installation Directory. There is also an online version of the documentation available from [DevNet](https://developer.cisco.com/docs/nso/nso-fundamentals/).
-
-```bash
-ls -l doc/
-drwxr-xr-x 5 user staff 160B Nov 29 05:19 api/
-drwxr-xr-x 14 user staff 448B Nov 29 05:19 html/
--rw-r--r-- 1 user staff 202B Nov 29 05:19 index.html
-drwxr-xr-x 17 user staff 544B Nov 29 05:19 pdf/
-```
-
-Run `index.html` in your browser to explore further.
-
-### Examples
-
-Local Install comes with a rich set of [examples](https://github.com/NSO-developer/nso-examples/tree/6.6) to start using NSO.
-
-```bash
-$ ls -1 examples.ncs/
-README.md
-aaa
-common
-device-management
-getting-started
-high-availability
-layered-services-architecture
-misc
-nano-services
-northbound-interfaces
-scaling-performance
-sdk-api
-service-management
-```
-
-### Network Element Drivers (NEDs)
-
-In order to communicate with the network, NSO uses NEDs as device drivers for different device types. Cisco has NEDs for hundreds of different devices available for customers, and several are included in the installer in the `/packages/neds` directory.
-
-In the example below, NEDs for Cisco ASA, IOS, IOS XR, and NX-OS are shown. Also included are NEDs for other vendors including Juniper JunOS, A10, ALU, and Dell.
-
-```bash
-$ ls -1 packages/neds
-a10-acos-cli-3.0
-alu-sr-cli-3.4
-cisco-asa-cli-6.6
-cisco-ios-cli-3.0
-cisco-ios-cli-3.8
-cisco-iosxr-cli-3.0
-cisco-iosxr-cli-3.5
-cisco-nx-cli-3.0
-dell-ftos-cli-3.0
-juniper-junos-nc-3.0
-```
-
-{% hint style="info" %}
-The example NEDs included in the installer are intended for evaluation, demonstration, and use with the [examples.ncs](https://github.com/NSO-developer/nso-examples/tree/6.6) examples. These are not the latest versions available and often do not have all the features available in production NEDs.
-{% endhint %}
-
-#### **Install New NEDs**
-
-A large number of pre-built supported NEDs are available which can be acquired and downloaded by the customers from [Cisco Software Download](https://software.cisco.com/). Note that the specific file names and versions that you download may be different from the ones in this guide. Therefore, remember to update the paths accordingly.
-
-Like the NSO installer, the NEDs are `signed.bin` files that need to be run to validate the download and extract the new code.
-
-To install new NEDs:
-
-1. Change to the working directory where your downloads are. The filenames indicate which version of NSO the NEDs are pre-compiled for (in this case NSO 6.0), and the version of the NED. An example output is shown below.
-
- ```bash
- cd ~/Downloads/
- ls -l ncs*.bin
-
- # Output
- -rw-r--r--@ 1 user staff 9708091 Dec 18 12:05 ncs-6.0-cisco-asa-6.7.7.signed.bin
- -rw-r--r--@ 1 user staff 51233042 Dec 18 12:06 ncs-6.0-cisco-ios-6.42.1.signed.bin
- -rw-r--r--@ 1 user staff 8400190 Dec 18 12:05 ncs-6.0-cisco-nx-5.13.1.1.signed.bin
- ```
-2. Use the `sh` command to run `signed.bin` to verify the certificate and extract the NED tar.gz and other files. Repeat for all files. An example output is shown below.
-
- ```bash
- sh ncs-6.0-cisco-nx-5.13.1.1.signed.bin
-
- Unpacking...
- Verifying signature...
- Downloading CA certificate from http://www.cisco.com/security/pki/certs/crcam2.cer ...
- Successfully downloaded and verified crcam2.cer.
- Downloading SubCA certificate from http://www.cisco.com/security/pki/certs/innerspace.cer ...
- Successfully downloaded and verified innerspace.cer.
- Successfully verified root, subca and end-entity certificate chain.
- Successfully fetched a public key from tailf.cer.
- Successfully verified the signature of ncs-6.0-cisco-nx-5.13.1.1.tar.gz using tailf.cer
- ```
-3. You now have three tar (.`tar.gz`) files. These are compressed versions of the NEDs. List the files to verify as shown in the example below.
-
- ```bash
- ls -l ncs*.tar.gz
- -rw-r--r-- 1 user staff 9704896 Dec 12 21:11 ncs-6.0-cisco-asa-6.7.7.tar.gz
- -rw-r--r-- 1 user staff 51260488 Dec 13 22:58 ncs-6.0-cisco-ios-6.42.1.tar.gz
- -rw-r--r-- 1 user staff 8409288 Dec 18 09:09 ncs-6.0-cisco-nx-5.13.1.1.tar.gz
- ```
-4. Navigate to the `packages/neds` directory for your Local Install, for example:
-
- ```bash
- cd ~/nso-6.0/packages/neds
- ```
-5. In the `/packages/neds` directory, extract the .tar files into this directory using the `tar` command with the path to where the compressed NED is located. An example is shown below.
-
- ```
- tar -zxvf ~/Downloads/ncs-6.0-cisco-nx-5.13.1.1.tar.gz
- tar -zxvf ~/Downloads/ncs-6.0-cisco-ios-6.42.1.tar.gz
- tar -zxvf ~/Downloads/ncs-6.0-cisco-asa-6.7.7.tar.gz
- ```
-
- \
- Here is a sample list of the newer NEDs extracted along with the ones bundled with the installation:
-
- ```
- drwxr-xr-x 13 user staff 416 Nov 29 05:17 a10-acos-cli-3.0
- drwxr-xr-x 12 user staff 384 Nov 29 05:17 alu-sr-cli-3.4
- drwxr-xr-x 13 user staff 416 Nov 29 05:17 cisco-asa-cli-6.6
- drwxr-xr-x 13 user staff 416 Dec 12 21:11 cisco-asa-cli-6.7
- drwxr-xr-x 12 user staff 384 Nov 29 05:17 cisco-ios-cli-3.0
- drwxr-xr-x 12 user staff 384 Nov 29 05:17 cisco-ios-cli-3.8
- drwxr-xr-x 13 user staff 416 Dec 13 22:58 cisco-ios-cli-6.42
- drwxr-xr-x 13 user staff 416 Nov 29 05:17 cisco-iosxr-cli-3.0
- drwxr-xr-x 13 user staff 416 Nov 29 05:17 cisco-iosxr-cli-3.5
- drwxr-xr-x 13 user staff 416 Nov 29 05:17 cisco-nx-cli-3.0
- drwxr-xr-x 14 user staff 448 Dec 18 09:09 cisco-nx-cli-5.13
- drwxr-xr-x 13 user staff 416 Nov 29 05:17 dell-ftos-cli-3.0
- drwxr-xr-x 10 user staff 320 Nov 29 05:17 juniper-junos-nc-3.0
- ```
-
-### Shell Scripts
-
-The last thing to note is the files `ncsrc` and `ncsrc.tsch`. These are shell scripts for `bash` and `tsch` that set up your PATH and other environment variables for NSO. Depending on your shell, you need to source this file before starting NSO.
-
-For more information on sourcing shell script, see the [Local Install steps](../local-install.md).
diff --git a/administration/installation-and-deployment/post-install-actions/migrate-to-system-install.md b/administration/installation-and-deployment/post-install-actions/migrate-to-system-install.md
deleted file mode 100644
index 55522933..00000000
--- a/administration/installation-and-deployment/post-install-actions/migrate-to-system-install.md
+++ /dev/null
@@ -1,125 +0,0 @@
----
-description: Convert your current Local Install setup to a System Install.
----
-
-# Migrate to System Install
-
-{% hint style="warning" %}
-Applies to Local Install.
-{% endhint %}
-
-If you already have a Local Install with existing data that you would like to convert into a System Install, the following procedure allows you to do so. However, a reverse migration from System to Local Install is not supported.
-
-{% hint style="info" %}
-It is possible to perform the migration and upgrade simultaneously to a newer NSO version, however, doing so introduces additional complexity. If you run into issues, first migrate, and then perform the upgrade.
-{% endhint %}
-
-The following procedure assumes that NSO is installed as described in the NSO Local Install process and will perform an initial System Install of the same NSO version. After following these steps, consult the NSO System Install guide for additional steps that are required for a fully functional System Install.
-
-The procedure also assumes you are using the `$HOME/ncs-run` folder as the run directory. If this is not the case, modify the following path accordingly.
-
-To migrate to System Install:
-
-1. Stop the current (local) NSO instance if it is running.
-
- ```bash
- $ ncs --stop
- ```
-2. Take a complete backup of the Runtime Directory for potential disaster recovery.
-
- ```bash
- $ tar -czf $HOME/ncs-backup.tar.gz -C $HOME ncs-run
- ```
-3. Change to Super User privileges.
-
- ```bash
- $ sudo -s
- ```
-4. Start the NSO System Install.
-
- ```bash
- $ sh nso-VERSION.OS.ARCH.installer.bin --system-install
- ```
-5. If you have multiple versions of NSO installed, verify that the symbolic link in `/opt/ncs` points to the correct version.
-6. Copy the CDB files containing data to the central location.
-
- ```bash
- # cp $HOME/ncs-run/ncs-cdb/*.cdb /var/opt/ncs/cdb
- ```
-7. Ensure that the `/var/opt/ncs/packages` directory includes all the necessary packages, appropriate for the NSO version. However, copying the packages directly could later on interfere with the operation of the `nct` command. It is better to only use symbolic links in that folder. Instead, copy the existing packages to the `/opt/ncs/packages` directory, either as directories or as tarball files. Make sure that each package includes the NSO version in its name and is not just a symlink, for example:
-
- ```bash
- # cd $HOME/ncs-run/packages
- # for pkg in *; do cp -RL $pkg /opt/ncs/packages/ncs-VERSION-$pkg; done
- ```
-8. Link to these packages in the `/var/opt/ncs/packages` directory.
-
- ```bash
- # cd /var/opt/ncs/packages/
- # rm -f *
- # for pkg in /opt/ncs/packages/ncs-VERSION-*; do ln -s $pkg; done
- ```
-
- \
- The reason for prepending `ncs-VERSION` to the filename is to allow additional NSO commands, such as `nct upgrade` and `software packages` to work properly. These commands need to identify which NSO version a package was compiled for.
-9. Edit the `/etc/ncs/ncs.conf` configuration file and make the necessary changes. If you wish to use the configuration from Local Install, disable the local authentication, unless you fully understand its security implications.
-
- ```xml
- Can we move NSO Installation from one folder to another?
- -Yes. You can move the directory where you installed NSO to a new location in your directory tree. Simply move NSO's root directory to the new desired location and update this file: `$NCS_DIR/ncsrc` (and `ncsrc.tcsh` if you want). This is a small and handy script that sets up some environment variables for you. Update the paths to the new location. The `$NCS_DIR/bin/ncs` and `$NCS_DIR/bin/ncsc` scripts will determine the location of NSO's root directory automatically. - -
-
-Not Sourcing the
-
-You have not sourced the `ncsrc` file:
-
-```bash
-$ ncs
--bash: ncs: command not found
-```
-
-
-
-Not Sourcing the ncsrc File
-
-You have not sourced the `ncsrc` file:
-
-```bash
-$ ncs
--bash: ncs: command not found
-```
-
-
-
-
-
-Not Starting NSO from the Runtime Directory
- -You are trying to start NSO from a directory that is not set up as a runtime directory. - -```bash -$ ncs -Bad configuration: /etc/ncs/ncs.conf:0: "./state/packages-in-use: \ - Failed to create symlink: no such file or directory" -Daemon died status=21 -``` - -What happened above is that NSO did not find an `ncs.conf` in the local directory, so it uses the default in `/etc/ncs/ncs.conf`. That `ncs.conf` says there shall be directories at `./` such as `./state` which is not true. Make sure that you `cd` to the root of the example and check that there is a `ncs.conf` file and a `cdb-dir` directory. - -
-
-
-
-Having Another Instance of NSO Running
- -You already have another instance of NSO running (or the same with netsim): - -```bash -$ ncs -Cannot bind to internal socket 127.0.0.1:4569 : address already in use -Daemon died status=20 -$ ncs-netsim start -DEVICE c0 Cannot bind to internal socket 127.0.0.1:5010 : \ - address already in use -Daemon died status=20 -FAIL -``` - -To resolve the above, just stop the running instance of NSO and netsim. Remember that it does not matter where you started the "running" NSO and netsim; there is no need to `cd` back to the other example before stopping. - -
-
-
diff --git a/administration/installation-and-deployment/post-install-actions/start-stop-nso.md b/administration/installation-and-deployment/post-install-actions/start-stop-nso.md
deleted file mode 100644
index 93030e72..00000000
--- a/administration/installation-and-deployment/post-install-actions/start-stop-nso.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-description: Start and stop the NSO daemon.
----
-
-# Start and Stop NSO
-
-{% hint style="warning" %}
-Applies to Local Install.
-{% endhint %}
-
-The command `ncs -h` shows various options when starting NSO. By default, NSO starts in the background without an associated terminal. It is recommended to add NSO to the `/etc/init` scripts of the deployment hosts. For more information, see the [ncs(1)](../../../resources/man/ncs.1.md) in Manual Pages.
-
-Whenever you start (or reload) the NSO daemon, it reads its configuration from `./ncs.conf` or `${NCS_DIR}/etc/ncs/ncs.conf` or from the file specified with the `-c` option. Parts of the configuration can also be placed in the `ncs.conf.d` directory that must be placed next to the actual `ncs.conf` file.
-
-```bash
-$ ncs
-$ ncs --stop
-$ ncs -h
-...
-```
diff --git a/administration/installation-and-deployment/post-install-actions/uninstall-local-install.md b/administration/installation-and-deployment/post-install-actions/uninstall-local-install.md
deleted file mode 100644
index d0287273..00000000
--- a/administration/installation-and-deployment/post-install-actions/uninstall-local-install.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-description: Remove Local Install.
----
-
-# Uninstall Local Install
-
-{% hint style="warning" %}
-Applies to Local Install.
-{% endhint %}
-
-To uninstall Local Install, simply delete the Install Directory.
diff --git a/administration/installation-and-deployment/post-install-actions/uninstall-system-install.md b/administration/installation-and-deployment/post-install-actions/uninstall-system-install.md
deleted file mode 100644
index f5a319f4..00000000
--- a/administration/installation-and-deployment/post-install-actions/uninstall-system-install.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-description: Remove System Install.
----
-
-# Uninstall System Install
-
-{% hint style="warning" %}
-Applies to System Install.
-{% endhint %}
-
-NSO can be uninstalled using the [ncs-installer(1)](../../../resources/man/ncs-installer.1.md) option only if NSO is installed with `--system-install` option. Either part of the static files or the full installation can be removed using `ncs-uninstall` option. Ensure to stop NSO before uninstalling.
-
-```bash
-# ncs-uninstall --all
-```
-
-Executing the above command removes the Installation Directory `/opt/ncs` including symbolic links, Configuration Directory `/etc/ncs`, Run Directory `/var/opt/ncs`, Log Directory `/var/log/ncs`, `systemd` service file `/etc/systemd/system/ncs.service`, `systemd`environment file `/etc/ncs/ncs.systemd.conf`, and the user profile scripts from `/etc/profile.d`.
-
-To make sure that no license entitlements are consumed after you have uninstalled NSO, be sure to perform the `deregister` command in the CLI:
-
-```cli
-admin@ncs# license smart deregister
-```
diff --git a/administration/installation-and-deployment/system-install.md b/administration/installation-and-deployment/system-install.md
deleted file mode 100644
index f0d5a5ea..00000000
--- a/administration/installation-and-deployment/system-install.md
+++ /dev/null
@@ -1,816 +0,0 @@
----
-description: Install NSO for production use in a system-wide deployment.
----
-
-# System Install
-
-## Installation Steps
-
-Complete the following activities in the given order to perform a System Install of NSO.
-
-Not Having the NetSim Device Configuration Loaded into NSO
- -Another problem that users run into sometimes is where the NetSim device configuration is not loaded into NSO. This can happen if the order of commands is not followed. To resolve this, remove the database files in the `ncs_cdb` directory (keep any files with the `.xml` extension). In this way, NSO will reload the XML initialization files provided by **ncs-setup**. - -```bash -$ ncs --stop -$ cd ncs-cdb/ -$ ls -A.cdb -C.cdb -O.cdb -S.cdb -netsim_devices_init.xml -$ rm *.cdb -$ ncs -``` - -
-
-
-
-Primary Requirements
- -Primary requirements to do a System Install include: - -* A system running Linux or macOS on either the `x86_64` or `ARM64` architecture for development. Linux for production. For [FIPS](https://www.nist.gov/itl/publications-0/federal-information-processing-standards-fips) mode, OS FIPS compliance may be required depending on your specific requirements. -* GNU libc 2.24 or higher. -* Java JRE 17 or higher. Used by Cisco Smart Licensing. -* Required and included with many Linux/macOS distributions: - * `tar` command. Unpack the installer. - * `gzip` command. Unpack the installer. - * `ssh-keygen` command. Generate SSH host key. - * `openssl` command. Generate self-signed certificates for HTTPS. - * `find` command. Used to find out if all required libraries are available. - * `which` command. Used by the NSO package manager. - * `libpam.so.0`. Pluggable Authentication Module library. - * `libexpat.so.1`. EXtensible Markup Language parsing library. - * `libz.so.1` version 1.2.7.1 or higher. Data compression library. - -
-
-
-
-Additional Requirements
- -Additional requirements to, for example, build and run NSO production deployment examples include: - -* Java JDK 17 or higher. -* Ant 1.9.8 or higher. -* Python 3.10 or higher. -* Python Setuptools is required to build the Python API. -* Often installed using the Python package installer pip: - * Python Paramiko 2.2 or higher. To use netconf-console. - * Python requests. Used by the RESTCONF demo scripts. -* `xsltproc` command. Used by the `support/ned-make-package-meta-data` command to generate the `package-meta-data.xml` file. -* One of the following web browsers is required for NSO GUI capabilities. The version must be supported by the vendor at the time of release. - * Safari - * Mozilla Firefox - * Microsoft Edge - * Google Chrome -* OpenSSH client applications. For example, `ssh` and `scp` commands. -* cron. Run time-based tasks, such as `logrotate`. -* `logrotate`. rotate, compress, and mail NSO and system logs. -* `rsyslog`. pass NSO logs to a local syslog managed by `rsyslogd` and pass logs to a remote node. -* `systemd` or `init.d` scripts to start and stop NSO. - -
-
-
-
-### Step 2 - Download the Installer and NEDs
-
-To download the Cisco NSO installer and example NEDs:
-
-1. Go to the Cisco's official [Software Download](https://software.cisco.com/download/home) site.
-2. Search for the product "Network Services Orchestrator" and select the desired version.
-3. There are two versions of the NSO installer, i.e. for macOS and Linux systems. For System Install, choose the Linux OS version.
-
-FIPS Mode Entropy Requirements
- -The following applies if you are running a container-based setup of your FIPS install: - -In containerized environments (e.g., Docker) that run on older Linux kernels (e.g., Ubuntu 18.04), `/dev/random` may block if the system’s entropy pool is low. This can lead to delays or hangs in FIPS mode, as cryptographic operations require high-quality randomness. - -To avoid this: - -* Prefer newer kernels (e.g., Ubuntu 22.04 or later), where entropy handling is improved to mitigate the issue. -* Or, install an entropy daemon like Haveged on the Docker host to help maintain sufficient entropy. - -Check available entropy on the host system with: - -```bash -cat /proc/sys/kernel/random/entropy_avail -``` - -A value of 256 or higher is generally considered safe. Reference: [Oracle blog post](https://blogs.oracle.com/linux/post/entropyavail-256-is-good-enough-for-everyone). - -
-
-
-
-### Step 3 - Unpack the Installer
-
-If your downloaded file is a `signed.bin` file, it means that it has been digitally signed by Cisco, and upon execution, you will verify the signature and unpack the `installer.bin`.
-
-If you only have `installer.bin`, skip to the next step.
-
-To unpack the installer:
-
-1. In the terminal, list the binaries in the directory where you downloaded the installer, for example:
-
- ```bash
- cd ~/Downloads
- ls -l nso*.bin
- -rw-r--r--@ 1 user staff 199M Dec 15 11:45 nso-6.0.linux.x86_64.installer.bin
- -rw-r--r--@ 1 user staff 199M Dec 15 11:45 nso-6.0.linux.x86_64.signed.bin
- ```
-2. Use the `sh` command to run the `signed.bin` to verify the certificate and extract the installer binary and other files. An example output is shown below.
-
- ```bash
- sh nso-6.0.linux.x86_64.signed.bin
- # Output
- Unpacking...
- Verifying signature...
- Downloading CA certificate from http://www.cisco.com/security/pki/certs/crcam2.cer ...
- Successfully downloaded and verified crcam2.cer.
- Downloading SubCA certificate from http://www.cisco.com/security/pki/certs/innerspace.cer ...
- Successfully downloaded and verified innerspace.cer.
- Successfully verified root, subca and end-entity certificate chain.
- Successfully fetched a public key from tailf.cer.
- Successfully verified the signature of nso-6.0.linux.x86_64.installer.bin using tailf.cer
- ```
-3. List the files to check if extraction was successful.
-
- ```bash
- ls -l
- # Output
- -rw-r--r-- 1 user staff 1.8K Nov 29 06:05 README.signature
- -rw-r--r-- 1 user staff 12K Nov 29 06:05 cisco_x509_verify_release.py
- -rwxr-xr-x 1 user staff 199M Nov 29 05:55 nso-6.0.linux.x86_64.installer.bin
- -rw-r--r-- 1 user staff 256B Nov 29 06:05 nso-6.0.linux.x86_64.installer.bin.signature
- -rwxr-xr-x@ 1 user staff 199M Dec 15 11:45 nso-6.0.linux.x86_64.signed.bin
- -rw-r--r-- 1 user staff 1.4K Nov 29 06:05 tailf.cer
- ```
-
-{% hint style="info" %}
-There may also be additional files present.
-{% endhint %}
-
-Identifying the Installer
- -You need to know your system specifications (Operating System and CPU architecture) to choose the appropriate NSO installer. - -NSO is delivered as an OS/CPU-specific signed self-extractable archive. The signed archive file has the pattern `nso-VERSION.OS.ARCH.signed.bin` that after signature verification extracts the `nso-VERSION.OS.ARCH.installer.bin` archive file, where: - -* `VERSION` is the NSO version to install. -* `OS` is the Operating System (`linux` for all Linux distributions and `darwin` for macOS). -* `ARCH` is the CPU architecture, for example`x86_64`. - -
-
-
-
-### Step 4 - Run the Installer
-
-To run the installer:
-
-1. Navigate to your Install Directory.
-2. Run the installer with the `--system-install` option to perform System Install. This option creates an install of NSO that is suitable for production deployment. At this point, you can choose to install NSO in standard mode or in FIPS mode.
-
-{% tabs %}
-{% tab title="Standard System Install" %}
-The standard mode is the regular NSO install and is suitable for most installations. FIPS is disabled in this mode.
-
-For standard NSO install, run the installer as below.
-
-```bash
-$ sudo sh nso-VERSION.OS.ARCH.installer.bin --system-install
-```
-
-{% code title="Example: Standard System Install" %}
-```bash
-$ sudo sh nso-6.0.linux.x86_64.installer.bin --system-install
-```
-{% endcode %}
-{% endtab %}
-
-{% tab title="FIPS System Install" %}
-FIPS mode creates a FIPS-compliant NSO install.
-
-FIPS mode should only be used for deployments that are subject to strict compliance regulations as the cryptographic functions are then confined to the CiscoSSL FIPS 140-3 module library.
-
-For FIPS-compliant NSO install, run the command with the additional `--fips-install` flag. Afterwards, verify FIPS in `ncs.conf`.
-
-```bash
-$ sudo sh nso-VERSION.OS.ARCH.installer.bin --system-install --fips-install
-```
-
-{% code title="Example: FIPS System Install" %}
-```bash
-$ sudo sh nso-6.5.linux.x86_64.installer.bin --system-install --fips-install
-```
-{% endcode %}
-
-{% hint style="info" %}
-**NSO Configuration for FIPS**
-
-Note the following as part of FIPS-specific configuration/install:
-
-1. The `ncs.conf` file is automatically configured to enable FIPS by setting the following flag:
-
-```xml
-Description of Unpacked Files
- -The following contents are unpacked: - -* `nso-VERSION.OS.ARCH.installer.bin`: The NSO installer. -* `nso-VERSION.OS.ARCH.installer.bin.signature`: Signature generated for the NSO image. -* `tailf.cer`: An enclosed Cisco-signed x.509 end-entity certificate containing the public key that is used to verify the signature. -* `README.signature`: File with further details on the unpacked content and steps on how to run the signature verification program. To manually verify the signature, refer to the steps in this file. -* `cisco_x509_verify_release.py`: Python program that can be used to verify the 3-tier x.509 certificate chain and signature. -* Multiple `.tar.gz` files: Bundled packages, extending the base NSO functionality. -* Multiple `.tar.gz.signature` files: Digital signatures for the bundled packages. - -Since NSO version 6.3, a few additional NSO packages are included. They contain the following platform tools: - -* HCC -* Observability Exporter -* Phased Provisioning -* Resource Manager - -For platform tools documentation, refer to the individual package's `README` file or to the [online documentation](https://nso-docs.cisco.com/resources). - -**NED Packages** - -The NED packages that are available with the NSO installation are netsim-based example NEDs. These NEDs are used for NSO examples only. - -Fetch the latest production-grade NEDs from [Cisco Software Download](https://software.cisco.com/download/home) using the URLs provided on your NED license certificates. - -**Manual Pages** - -The installation program will unpack the NSO manual pages from the documentation archive, allowing you to use the `man` command to view them. The Manual Pages are also available in PDF format and from the online documentation located on [NCS man-pages, Volume 1](../../resources/man/ncs-installer.1.md) in Manual Pages. - -Following is a list of a few of the installed manual pages: - -* `ncs(1)`: Command to start and control the NSO daemon. -* `ncsc(1)`: NSO Yang compiler. -* `ncs_cli(1)`: Frontend to the NSO CLI engine. -* `ncs-netsim(1)`: Command to create and manipulate a simulated network. -* `ncs-setup(1)`: Command to create an initial NSO setup. -* `ncs.conf`: NSO daemon configuration file format. - -For example, to view the manual page describing the NSO configuration file, you should type: - -```bash -$ man ncs.conf -``` - -Apart from the manual pages, extensive information about command line options can be obtained by running `ncs` and `ncsc` with the `--help` (abbreviated `-h`) flag. - -```bash -$ ncs --help -``` - -```bash -$ ncsc --help -``` - -**Installer Help** - -Run the `sh nso-VERSION.linux.x86_64.installer.bin --help` command to view additional help on running binaries. More details can be found in the [ncs-installer(1)](../../resources/man/ncs-installer.1.md) Manual Page included with NSO. - -Notice the two options for `--local-install` or `--system-install`. - -```bash -sh nso-6.0.linux.x86_64.installer.bin --help -``` - -
-
-
-
-Default Directories and Scripts
- -The System Install by default creates the following directories: - -* The Installation Directory is created in `/opt/ncs`, where the distribution is available. -* The Configuration Directory is created in `/etc/ncs`, where the `ncs.conf` file, SSH keys, and WebUI certificates are created. -* The Running Directory is created in `/var/opt/ncs`, where runtime state files, CDB database, and packages are created. -* The Log Directory is created in `/var/log/ncs`, where the log files are populated. -* System-wide environment variables are created in `/etc/profile.d/ncs.sh`. -* The installer creates a `systemd` system service script in `/etc/systemd/system/ncs.service` and enables the NSO service to start at boot, but the service is _not_ started immediately. See the steps below for starting NSO after installation and before rebooting. -* To allow package reload when starting NSO, an environment file called `/etc/ncs/ncs.systemd.conf` is created. This file is owned by the user that starts NSO. - -For the `--system-install` option, you can also choose a user-defined (non-default) Installation Directory, Configuration Directory, Running Directory, and Log Directory with `--install-dir`, `--config-dir`, `--run-dir` and `--log-dir` parameters, and specify that NSO should run as a different user than root with the `--run-as-user` parameter. - -If you choose a non-default Installation Directory by using `--install-dir`, you need to specify `--install-dir` for subsequent installs and also for backup and restore. - -Use the `--ignore-init-scripts` option to disable provisioning the `systemd` system service. - -If a legacy SysV service exists in `/etc/init.d/ncs` when installing in interactive mode, the user will be prompted to continue using the old SysV service behavior or prepare a `systemd` service. In non-interactive mode, a `systemd` service will be prepared where a `/etc/systemd/system/ncs.service.prepare` file is created. The service is not enabled to start at boot. To enable it, rename it to `/etc/systemd/system/ncs.service` and remove the old `/etc/init.d/ncs` SysV service. When using the `--non-interactive` option, the `/etc/systemd/system/ncs.service` file will be overwritten if it already exists. - -For more information on the `ncs-installer`, see the [ncs-installer(1)](../../resources/man/ncs-installer.1.md) man page. - -For an extensive guide to NSO deployment, refer to [Development to Production Deployment](development-to-production-deployment/)_._ - -
-
- # if not using overcommit_kbytes
-vm.overcommit_kbytes = # if using a fixed CommitLimit
-vm.swappiness = 1
-```
-{% endcode %}
-
-See the Linux [sysctl.conf(5)](https://man7.org/linux/man-pages/man5/sysctl.conf.5.html) manual page for details.
-
-**NSO Crash Dumps**
-
-If NSO aborts due to failure to allocate memory, NSO will produce a system dump by default before aborting. When starting NSO from a non-root user, set the `NCS_DUMP` environment variable to point to a filename in a directory that the non-root user can access. The default setting is `NCS_DUMP=ncs_crash.dump`, where the file is written to the NSO run-time directory, typically `NCS_RUN_DIR=/var/opt/ncs`. If the user running NSO cannot write to the directory that the `NCS_DUMP` environment variable points to, generating the system dump file will fail, and the debug information will be lost.
-
-#### **Alternative: Heuristic Overcommit Mode (vm.overcommit\_memory=0) With Committed\_AS Monitoring**
-
-As an alternative to the recommended strict mode, `vm.overcommit_memory=2`, you can keep `vm.overcommit_memory=0` to allow overcommit of memory and monitor the total committed memory (Committed\_AS) versus CommitLimit using, for example, a best effort script or observability tool. When Committed\_AS crosses a threshold, for example, 90% of CommitLimit, proactively trigger a series of NSO debug dumps every few seconds via `ncs --debug-dump`. Optionally, a second critical threshold, for example, 95% of CommitLimit, proactively trigger NSO to produce a system dump and then exit gracefully.
-
-* This approach does not prevent NSO from getting killed; it attempts to capture diagnostic data before memory pressure becomes critical and the Linux OOM-killer kills NSO.
-* If swap is enabled, prefer vm.swappiness=1 and consider placing NSO in a cgroup with memory.swap.max=0 to avoid swap I/O for NSO. Requires Linux cgroup v2 and a service-managed cgroup (e.g., systemd) support.
-
-- Committed\_AS versus CommitLimit is a more meaningful early‑warning signal than Committed\_AS versus MemTotal, because CommitLimit reflects the kernel’s current overcommit policy, swap availability, and huge page reservations—MemTotal does not.
-- When in Heuristic mode (vm.overcommit\_memory=0): CommitLimit is informative, not enforced. It’s still better than MemTotal for early warning, but OOM can occur before or after you reach it.
-- If necessary for your use-case, complement with MemAvailable, swap activity (vmstat or /proc/vmstat), PSI memory pressure (/proc/pressure/memory), and per‑process/cgroup RSS to catch imminent pressure that Committed\_AS alone may miss.
-- Ensure the user running the monitor has permission to execute `ncs --debug-dump` and write to the chosen dump directory.
-- See "NSO Crash Dumps" above for crash dump details.
-
-{% code title="Simple example script NSO debug-dump monitor" overflow="wrap" %}
-```bash
-#!/usr/bin/env bash
-# Simple NSO debug-dump monitor for heuristic overcommit mode (vm.overcommit_memory=0).
-# Triggers ncs --debug-dump when Committed_AS reaches 90% of CommitLimit.
-# Triggers NSO to produce a system dump before exiting using kill -USR1 when Committed_AS reaches 95% of CommitLimit
-
-THRESHOLD_PCT=90 # Trigger at 90% of CommitLimit (10% headroom).
-CRITICAL_PCT=95 # Trigger at 95% of CommitLimit (5% headroom).
-POLL_INTERVAL=5 # Seconds between checks.
-PROCESS_CHECK_INTERVAL=30
-DUMP_COUNT=10 # Number of dumps to collect.
-DUMP_DELAY=10 # Seconds between dumps.
-DUMP_PREFIX="dump" # Files like dump.1.bin, dump.2.bin, ...
-
-command -v ncs >/dev/null 2>&1 || { echo "ncs command not found in PATH."; exit 1; }
-
-find_nso_pid() {
- pgrep -x ncs.smp | head -n1 || true
-}
-
-while true; do
- pid="$(find_nso_pid)"
- if [ -z "${pid:-}" ]; then
- echo "NSO not running; retry in ${PROCESS_CHECK_INTERVAL}s..."
- sleep "$PROCESS_CHECK_INTERVAL"
- continue
- fi
-
- committed="$(awk '/Committed_AS:/ {print $2}' /proc/meminfo)"
- commit_limit="$(awk '/CommitLimit:/ {print $2}' /proc/meminfo)"
- if [ -z "$committed" ] || [ -z "$commit_limit" ]; then
- echo "Unable to read /proc/meminfo; retry in ${POLL_INTERVAL}s..."
- sleep "$POLL_INTERVAL"
- continue
- fi
-
- threshold=$(( commit_limit * THRESHOLD_PCT / 100 ))
- critical=$(( commit_limit * CRITICAL_PCT / 100 ))
- echo "PID=${pid} Committed_AS=${committed}kB; CommitLimit=${commit_limit}kB; Threshold=${threshold}kB; Critical=${critical}kB."
- if [ "$committed" -ge "$critical" ]; then
- echo "Critical threshold crossed; collect a system dump and stop NSO..."
- kill -USR1 ${pid}
- exit 0
- elif [ "$committed" -ge "$threshold" ]; then
- echo "Threshold crossed; collecting ${DUMP_COUNT} debug dumps..."
- for i in $(seq 1 "$DUMP_COUNT"); do
- file="${DUMP_PREFIX}.${i}.bin"
- echo "Dump $i -> ${file}"
- if ! ncs --debug-dump "$file"; then
- echo "Debug dump $i failed."
- fi
- sleep "$DUMP_DELAY"
- done
- echo "All debug dumps completed; exiting."
- exit 0
- fi
-
- sleep "$POLL_INTERVAL"
-done
-```
-{% endcode %}
-
-
-
-{% hint style="info" %}
-Some older NSO releases expect the `/etc/init.d/` folder to exist in the host operating system. If the folder does not exist, the installer may fail to successfully install NSO. A workaround that allows the installer to proceed is to create the folder manually, but the NSO process will not automatically start at boot.
-{% endhint %}
-
-### Step 5 - Set Up User Access
-
-The installation is configured for PAM authentication, with group assignment based on the OS group database (e.g. `/etc/group` file). Users that need access to NSO must belong to either the `ncsadmin` group (for unlimited access rights) or the `ncsoper` group (for minimal access rights).
-
-To set up user access:
-
-1. To create the `ncsadmin` group, use the OS shell command:
-
- ```bash
- # groupadd ncsadmin
- ```
-2. To create the `ncsoper` group, use the OS shell command:
-
- ```bash
- # groupadd ncsoper
- ```
-3. To add an existing user to one of these groups, use the OS shell command:
-
- ```bash
- # usermod -a -G 'groupname' 'username'
- ```
-
-### Step 6 - Set Environment Variables
-
-To set environment variables:
-
-1. Change to Super User privileges.
-
- ```bash
- $ sudo -s
- ```
-2. The installation program creates a shell script file in each NSO installation which sets the environment variables needed to run NSO. With the `--system-install` option, by default, these settings are set on the shell. To explicitly set the variables, source `ncs.sh` or `ncs.csh` depending on your shell type.
-
- ```bash
- # source /etc/profile.d/ncs.sh
- ```
-3. Start NSO.
-
- ```bash
- # systemctl daemon-reload
- # systemctl start ncs
- ```
-
- NSO starts at boot going forward.
-
- Once you log on with the user that belongs to `ncsadmin` or `ncsoper`, you can directly access the CLI as shown below:
-
- ```bash
- $ ncs_cli -C
- ```
-
-### Step 7 - Runtime Directory Creation
-
-As part of the System Install, the NSO daemon `ncs` is automatically started at boot time. You do not need to create a Runtime Directory for System Install.
-
-### Step 8 - Generate License Registration Token
-
-To conclude the NSO installation, a license registration token must be created using a (CSSM) account. This is because NSO uses [Cisco Smart Licensing](../management/system-management/cisco-smart-licensing.md) to make it easy to deploy and manage NSO license entitlements. Login credentials to the [Cisco Smart Software Manager](https://www.cisco.com/c/en/us/buy/smart-accounts/software-manager.html) (CSSM) account are provided by your Cisco contact and detailed instructions on how to [create a registration token](../management/system-management/cisco-smart-licensing.md#d5e2927) can be found in the Cisco Smart Licensing. General licensing information covering licensing models, how licensing works, usage compliance, etc., is covered in the [Cisco Software Licensing Guide](https://www.cisco.com/c/en/us/buy/licensing/licensing-guide.html).
-
-To generate a license registration token:
-
-1. When you have a token, start a Cisco CLI towards NSO and enter the token, for example:
-
- ```bash
- $ ncs_cli -Cu admin
- admin@ncs# license smart register idtoken
- YzIzMDM3MTgtZTRkNC00YjkxLTk2ODQtOGEzMTM3OTg5MG
-
- Registration process in progress.
- Use the 'show license status' command to check the progress and result.
- ```
-
- \
- Upon successful registration, NSO automatically requests a license entitlement for its own instance and for the number of devices it orchestrates and their NED types. If development mode has been enabled, only development entitlement for the NSO instance itself is requested.
-2. Inspect the requested entitlements using the command `show license all` (or by inspecting the NSO daemon log). An example output is shown below.
-
- ```bash
- admin@ncs# show license all
- ...
- Enable Strict Overcommit Accounting on the Host.
- -By default, the Linux kernel allows overcommit of memory. However, memory overcommit produces an unexpected and unreliable environment for NSO because the Linux Out-Of-Memory (OOM) killer may terminate NSO without restarting it if the system is critically low on memory. Also, when the OOM killer terminates NSO, no system dump file will be produced, and the debug information will be lost. Thus, it is strongly recommended to enable strict overcommit accounting. - -#### **Heuristic Overcommit Mode as an Alternative to Strict Overcommit** - -The alternative—using heuristic overcommit mode (see below for best‑effort recommendations)—can be useful if the NSO host has severe memory limitations. For example, if RAM sizing for the NSO host did not take into account that the schema (from YANG models) is loaded into memory by NSO Python and Java packages affecting total committed memory (Committed\_AS) and after considering the recommendations in [CDB Stores the YANG Model Schema](../../development/advanced-development/scaling-and-performance-optimization.md#d5e8743). - -#### Recommended: Host Configured for Strict Overcommit - -* Set `vm.overcommit_memory=2` to enable strict overcommit accounting. -* Set `vm.overcommit_ratio` so the CommitLimit is approximately equal to physical RAM, with a 5% headroom for the kernel to reduce the risk of system-wide OOM conditions. E.g., 95% of RAM when no swap is present (recommended), or subtract 5 percentage points from the calculated ratio that neutralizes swap. Increase the headroom if the host runs additional services. -* Alternatively, set `vm.overcommit_kbytes` which takes precedence; `vm.overcommit_ratio` is ignored while `vm.overcommit_kbytes > 0`. - * When vm.overcommit\_kbytes > 0, it sets a fixed CommitLimit in kB and ignores ratio and swap in the calculation. Note that HugeTLB is not subtracted when overcommit\_kbytes is used (it’s a fixed value). -* Strongly discourage swap use at runtime by setting `vm.swappiness=1`. -* If swap must remain enabled system-wide, prevent NSO from using swap by configuring its cgroup with `memory.swap.max=0` (cgroup v2). -* If swap must be enabled for NSO use a fast disk, for example, an NVMe SSD. - -**Apply Immediately** - -{% code title="To apply strict overcommit accounting with immediate effect" %} -```bash -echo 2 > /proc/sys/vm/overcommit_memory -``` -{% endcode %} - -When `vm.overcommit_memory=2`, the overcommit\_ratio parameter defines the percentage of physical RAM that is available for commit. - -The Linux kernel computes the CommitLimit: - -CommitLimit = MemTotal × (overcommit\_ratio / 100) + SwapTotal − total\_huge\_TLB - -* MemTotal is the total amount of RAM on the system. -* overcommit\_ratio is the value in `/proc/sys/vm/overcommit_ratio` . -* SwapTotal is the amount of swap space. Can be 0. -* total\_huge\_TLB is the amount of memory set aside for huge pages. Can be 0. - -The default overcommit\_ratio is 50%. On systems with more than 50% of RAM available, this default can underutilize physical memory. - -Do not set `vm.overcommit_ratio=100` as it includes all RAM plus all swap in the CommitLimit and leaves no headroom for the kernel. While swap increases the commit capacity, it is usually slow and should be avoided for NSO. - -**Compute overcommit\_ratio to Neutralize Swap** - -To allocate physical RAM only in commit accounting and keep a 5-10% headroom for the kernel: - -* Compute the base ratio: base\_ratio = 100 × (MemTotal − SwapTotal) / MemTotal. -* Apply headroom: overcommit\_ratio = floor(base\_ratio) − 5. - -Notes: - -* overcommit\_ratio is an integer; round down for a bit of extra headroom. -* Recompute the ratio if RAM or swap changes. -* If SwapTotal ≥ MemTotal, swap cannot be neutralized via overcommit\_ratio, use overcommit\_kbytes; see Example 3. -* If the computed value is very low, ensure it still fits your workload requirements. - -**Example 1: No Swap, 5% Headroom** - -{% code title="Check memory totals" %} -```bash -cat /proc/meminfo | grep "MemTotal\|SwapTotal" -MemTotal: 8039352 kB -SwapTotal: 0 kB -``` -{% endcode %} - -{% code title="Apply settings with immediate effect" %} -```bash -echo 2 > /proc/sys/vm/overcommit_memory -echo 95 > /proc/sys/vm/overcommit_ratio -echo 1 > /proc/sys/vm/swappiness -``` -{% endcode %} - -Rationale: With no swap, set overcommit\_ratio=95 to allow \~95% of RAM for user-space commit, leaving \~5% headroom for the kernel. - -**Example 2: MemTotal > SwapTotal, Neutralize Swap with 5% Headroom** - -{% code title="Check memory totals" %} -```bash -cat /proc/meminfo | grep "MemTotal\|SwapTotal" -MemTotal: 8039352 kB -SwapTotal: 1048572 kB -``` -{% endcode %} - -Calculate the ratio: - -* base\_ratio= 100 × ((8039352 − 1048572) / 8039352) ≈ 86.9%. -* Apply 5% headroom: overcommit\_ratio = floor(86.9) − 5 = 81. - -{% code title="Apply" %} -```bash -echo 2 > /proc/sys/vm/overcommit_memory -echo 81 > /proc/sys/vm/overcommit_ratio -echo 1 > /proc/sys/vm/swappiness -``` -{% endcode %} - -This keeps the CommitLimit safely below physical RAM to provide kernel headroom and neutralizes swap’s contribution to CommitLimit and then applies 5% headroom toward the commit budget. - -**Example 3: SwapTotal ≥ MemTotal (Headroom via ratio not applicable, use overcommit\_kbytes)** - -{% code title="Check memory totals" %} -```bash -cat /proc/meminfo | grep "MemTotal\|SwapTotal" -MemTotal: 16000000 kB -SwapTotal: 16000000 kB -``` -{% endcode %} - -Compute: - -* CommitLimit\_kB = floor(MemTotal × 0.95) = floor(16,000,000 × 0.95) = 15,200,000 kB. - -{% code title="Apply" %} -```bash -echo 2 > /proc/sys/vm/overcommit_memory -echo 15200000 > /proc/sys/vm/overcommit_kbytes -echo 1 > /proc/sys/vm/swappiness -``` -{% endcode %} - -Note that overcommit\_kbytes sets a fixed CommitLimit that ignores swap; recompute if RAM changes. Also note the HugeTLB subtraction does not apply when using overcommit\_kbytes (fixed commit budget). - -Refer to the Linux [proc\_sys\_vm(5)](https://man7.org/linux/man-pages/man5/proc_sys_vm.5.html) manual page for more details on the overcommit\_memory, overcommit\_ratio, and overcommit\_kbytes parameters. - -**Persist Across Reboots** - -To ensure the overcommit remains disabled after reboot, add the three lines below to `/etc/sysctl.conf` (or a file under `/etc/sysctl.d/`). - -{% code title="Add to /etc/sysctl.conf" %} -``` -vm.overcommit_memory = 2 -vm.overcommit_ratio =
-
- 13-Apr-2016::13:22:29.178 miosaterm confd[16260]:
-Starting the NCS Smart Licensing Java VM
- 13-Apr-2016::13:22:34.737 miosaterm confd[16260]:
-Smart Licensing evaluation time remaining: 90d 0h 0m 0s
-...
- 13-Apr-2016::13:22:34.737 miosaterm confd[16260]:
-Smart Licensing evaluation time remaining: 89d 23h 0m 0s
-...
-```
-
-
-
-Evaluation Period
- -If no registration token is provided, NSO enters a 90-day evaluation period and the remaining evaluation time is recorded hourly in the NSO daemon log: - -``` - ... -
-
-
-
-Communication Send Error
- -During upgrades, if you experience a 'Communication Send Error' during license registration, restart the Smart Agent. - -
-
-` to point to the satellite.
-
-Another option when direct access is not desired is to configure an HTTP or HTTPS proxy, e.g., `smart-license smart-agent proxy url https://127.0.0.1:8080`. If you plan to do this, take the note below regarding ignored CLI configurations into account:
-
-If `ncs.conf` contains a configuration for any of the java-executable, java-options, override-url/url, or proxy/url under the configure path `/ncs-config/smart-license/smart-agent/`, then any corresponding configuration done via the CLI is ignored.
-
-
-
-If You are Unable to Access Cisco Smart Software Manager
- -In a situation where the NSO instance has no direct access to the Cisco Smart Software Manager, one option is the [Cisco Smart Software Manager Satellite](https://software.cisco.com/software/csws/ws/platform/home) which can be installed to manage software licenses on the premises. Install the satellite and use the command `call-home destination address http
-
-
-
-License Registration in HA Mode
- -When configuring NSO in High Availability (HA) mode, the license registration token must be provided to the CLI running on the primary node. Read more about HA and node types in [High Availability](../management/high-availability.md)_._ - -
-
- 21-Apr-2016::11:29:18.022 miosaterm confd[8226]:
-Smart Licensing Global Notification:
-type = "notifyRegisterSuccess"
-```
-
-
-
-Licensing Log
- -Licensing activities are also logged in the NSO daemon log as described in [Monitoring NSO](../management/system-management/#d5e7876). For example, a successful token registration results in the following log entry: - -``` -
-
-
-
-## System Install FAQs
-
-Frequently Asked Questions (FAQs) about System Install.
-
-Check Registration Status
- -To check the registration status, use the command `show license status`. - -```bash -admin@ncs# show license status - -Smart Licensing is ENABLED - -Registration: -Status: REGISTERED -Smart Account: Network Services Orchestrator -Virtual Account: Default -Export-Controlled Functionality: Allowed -Initial Registration: SUCCEEDED on Apr 21 09:29:11 2016 UTC -Last Renewal Attempt: SUCCEEDED on Apr 21 09:29:16 2016 UTC -Next Renewal Attempt: Oct 18 09:29:16 2016 UTC -Registration Expires: Apr 21 09:26:13 2017 UTC -Export-Controlled Functionality: Allowed - -License Authorization: - -License Authorization: -Status: IN COMPLIANCE on Apr 21 09:29:18 2016 UTC -Last Communication Attempt: SUCCEEDED on Apr 21 09:26:30 2016 UTC -Next Communication Attempt: Apr 21 21:29:32 2016 UTC -Communication Deadline: Apr 21 09:26:13 2017 UTC -``` - -
-
-
-
-Is there a dependency between the NSO Installation Directory and Runtime Directory?
- -No, there is no such dependency. - -
-
-Do you need to source the
-
-No. By default, the environment variables are configured and set on the shell with System Install.
-
-
-
-Do you need to source the ncsrc file before starting NSO?
-
-No. By default, the environment variables are configured and set on the shell with System Install.
-
-
-
-
-
-Can you start NSO from a directory that is not an NSO runtime directory?
- -Yes. - -
-
-
-
-Can you stop NSO from a directory that is not an NSO runtime directory?
- -Yes. - -
-
-
-
-For evaluation and development purposes, instead of a Local Install, you performed a System Install. Now you cannot build or run NSO examples as described in README files. How can you proceed further?
- -The easiest way is to uninstall the System install using `ncs-uninstall --all` and do a Local Install from scratch. - -
-
-
diff --git a/administration/installation-and-deployment/upgrade-nso.md b/administration/installation-and-deployment/upgrade-nso.md
deleted file mode 100644
index 13b05ed4..00000000
--- a/administration/installation-and-deployment/upgrade-nso.md
+++ /dev/null
@@ -1,501 +0,0 @@
----
-description: Upgrade NSO to a higher version.
----
-
-# Upgrade NSO
-
-Upgrading the NSO software gives you access to new features and product improvements. Every change carries a risk, and upgrades are no exception. To minimize the risk and make the upgrade process as painless as possible, this section describes the recommended procedures and practices to follow during an upgrade.
-
-As usual, sufficient preparation avoids many pitfalls and makes the process more straightforward and less stressful.
-
-## Preparing for Upgrade
-
-There are multiple aspects that you should consider before starting with the actual upgrade procedure. While the development team tries to provide as much compatibility between software releases as possible, they cannot always avoid all incompatible changes. For example, when a deviation from an RFC standard is found and resolved, it may break clients that depend on the non-standard behavior. For this reason, a distinction is made between maintenance and a major NSO upgrade.
-
-A maintenance NSO upgrade is within the same branch, i.e., when the first two version numbers stay the same (x.y in the x.y.z NSO version). An example is upgrading from version 6.2.1 to 6.2.2. In the case of a maintenance upgrade, the NSO release contains only corrections and minor enhancements, minimizing the changes. It includes binary compatibility for packages, so there is no need to recompile the .fxs files for a maintenance upgrade.
-
-Correspondingly, when the first or second number in the version changes, that is called a full or major upgrade. For example, upgrading version 6.3.1 to 6.4 is a major, non-maintenance upgrade. Due to new features, packages must be recompiled, and some incompatibilities could manifest.
-
-In addition to the above, a package upgrade is when you replace a package with a newer version, such as a NED or a service package. Sometimes, when package changes are not too big, it is possible to supply the new packages as part of the NSO upgrade, but this approach brings additional complexity. Instead, package upgrade and NSO upgrade should in general, be performed as separate actions and are covered as such.
-
-To avoid surprises during any upgrade, first ensure the following:
-
-* Hosts have sufficient disk space, as some additional space is required for an upgrade.
-* The software is compatible with the target OS. However, sometimes a newer version of Java or system libraries, such as glibc, may be required.
-* All the required NEDs and custom packages are compatible with the target NSO version. If you're planning to run the upgraded version in FIPS-compliant mode, make sure to upgrade the NEDs to the latest version.
-* Existing packages have been compiled for the new version and are available to you during the upgrade.
-* Check whether the existing `ncs.conf` file can be used as-is or needs updating. For example, stronger encryption algorithms may require you to configure additional keying material.
-* Review the `CHANGES` file for information on what has changed.
-* If upgrading from a no longer supported software version, verify that the upgrade can be performed directly. In situations where the currently installed version is very old, you may have to upgrade to one or more intermediate versions before upgrading to the target version.
-
-In case it turns out that any of the packages are incompatible or cannot be recompiled, you will need to contact the package developers for an updated or recompiled version. For an official Cisco-supplied package, it is recommended that you always obtain a pre-compiled version if it is available for the target NSO release, instead of compiling the package yourself.
-
-Additional preparation steps may be required based on the upgrade and the actual setup, such as when using the Layered Service Architecture (LSA) feature. In particular, for a major NSO upgrade in a multi-version LSA cluster, ensure that the new version supports the other cluster members and follow the additional steps outlined in [Deploying LSA](../advanced-topics/layered-service-architecture.md#deploying-lsa) in Layered Service Architecture.
-
-If you use the High Availability (HA) feature, the upgrade consists of multiple steps on different nodes. To avoid mistakes, you are encouraged to script the process, for which you will need to set up and verify access to all NSO instances with either `ssh`, `nct`, or some other remote management command. For the reference example, we use in this chapter, see [examples.ncs/high-availability/hcc](https://github.com/NSO-developer/nso-examples/tree/6.6/high-availability/hcc). The management station uses shell and Python scripts that use `ssh` to access the Linux shell and NSO CLI and Python Requests for NSO RESTCONF interface access.
-
-Likewise, NSO 5.3 added support for 256-bit AES encrypted strings, requiring the AES256CFB128 key in the `ncs.conf` configuration. You can generate one with the `openssl rand -hex 32` or a similar command. Alternatively, if you use an external command to provide keys, ensure that it includes a value for an `AES256CFB128_KEY` in the output.
-
-With regard to init system, NSO 6.4 introduces `systemd` as the default option instead of SysV. In interactive mode, when upgrading to NSO 6.4 and later, the installer prompts the user to continue using the old SysV service or prepare a `systemd` service. In non-interactive mode, a `systemd` service is prepared by default. When using the `--non-interactive` option, the `/etc/systemd/system/ncs.service` file will be overwritten if it already exists.
-
-Finally, regardless of the upgrade type, ensure that you have a working backup and can easily restore the previous configuration if needed, as described in [Backup and Restore](../management/system-management/#backup-and-restore).
-
-{% hint style="danger" %}
-**Caution**
-
-The `ncs-backup` (and consequently the `nct backup`) command does not back up the `/opt/ncs/packages` folder. If you make any file changes, back them up separately.
-
-However, the best practice is not to modify packages in the `/opt/ncs/packages` folder. Instead, if an upgrade requires package recompilation, separate package folders (or files) should be used, one for each NSO version.
-{% endhint %}
-
-## Single Instance Upgrade
-
-The upgrade of a single NSO instance requires the following steps:
-
-1. Create a backup.
-2. Perform a System Install of the new version.
-3. Stop the old NSO server process.
-4. Compact the CDB files write log.
-5. Update the `/opt/ncs/current` symbolic link.
-6. If required, update the `ncs.conf` configuration file.
-7. Update the packages in `/var/opt/ncs/packages/` if recompilation is needed.
-8. Start the NSO server process, instructing it to reload the packages.
-
-{% hint style="info" %}
-The following steps assume that you are upgrading to the 6.5 release. They pertain to a System Install of NSO, and you must perform them with Super User privileges.
-
-If you're upgrading from a non-FIPS setup to a [FIPS](https://www.nist.gov/itl/publications-0/federal-information-processing-standards-fips)-compliant setup, ensure that the system requirements comply to FIPS mode install. This entails considering FIPS compliance at OS level as well as configuring NSO to use only FIPS-validated algorithms for keys and certificates.
-{% endhint %}
-
-{% stepper %}
-{% step %}
-As a best practice, always create a backup before trying to upgrade.
-
-```bash
-# ncs-backup
-```
-{% endstep %}
-
-{% step %}
-For the upgrade itself, you must first download to the host and install the new NSO release. At this point, you can choose to install NSO in standard mode or in FIPS mode.
-
-{% tabs %}
-{% tab title="Standard System Install" %}
-The standard mode is the regular NSO install and is suitable for most installations. FIPS is disabled in this mode.
-
-For standard NSO installation, run the installer as below:
-
-```bash
-# sh nso-6.5.linux.x86_64.installer.bin --system-install
-```
-{% endtab %}
-
-{% tab title="FIPS System Install" %}
-FIPS mode creates a FIPS-compliant NSO install.
-
-FIPS mode should only be used for deployments that are subject to strict compliance regulations as the cryptographic functions are then confined to the CiscoSSL FIPS 140-3 module library.
-
-For FIPS-compliant NSO install, run the installer with the additional `--fips-install` flag. Afterwards, if needed, enable FIPS in `ncs.conf` as described further below.
-
-```bash
-# sh nso-6.5.linux.x86_64.installer.bin --system-install --fips-install
-```
-{% endtab %}
-{% endtabs %}
-{% endstep %}
-
-{% step %}
-Stop the currently running server with the help of `systemd` or an equivalent command relevant to your system.
-
-```bash
-# systemctl stop ncs
-Stopping ncs: .
-```
-{% endstep %}
-
-{% step %}
-Compact the CDB files write log using, for example, the `ncs --cdb-compact $NCS_RUN_DIR/cdb` command.
-{% endstep %}
-
-{% step %}
-Next, you update the symbolic link for the currently selected version to point to the newly installed one, 6.5 in this case.
-
-```bash
-# cd /opt/ncs
-# rm -f current
-# ln -s ncs-6.5 current
-```
-{% endstep %}
-
-{% step %}
-While seldom necessary, at this point, you would also update the `/etc/ncs/ncs.conf` file. If you ran the installer with FIPS mode, update `ncs.conf` accordingly.
-
-{% hint style="info" %}
-**NSO Configuration for FIPS**
-
-Note the following as part of FIPS-specific configuration:
-
-1. If you're upgrading from a non-FIPS version (e.g., 6.4) to a FIPS-compliant version (e.g., 6.5), the following `ncs.conf` entry needs to be manually added to enable FIPS. Afterwards, upon upgrading between FIPS-compliant versions, the existing entry automatically updates, eliminating the need for any manual intervention.
-
-```xml
-Can we move NSO Installation from one folder to another ?
- -No. - -
Primary - Secondary Configuration
One Primary - Several Secondaries
| Action | Description |
|---|---|
create-cluster | Initialize an HA Raft cluster. This action should only be invoked once to form a new cluster when no HA Raft log exists. The members of the HA Raft cluster consist of the NCS node where the /ha-raft/create-clusteraction is invoked, which will become the leader of the cluster; and the members specified by the member parameter. |
adjust-membership | Add or remove an HA node from the HA Raft cluster. |
disconnect | Disconnect an HA node from all remaining nodes. In the event of revoking a TLS certificate, invoke this action to disconnect the already established connections to the node with the revoked certificate. A disconnected node with a valid TLS certificate may re-establish the connection. |
reset | Reset the (disabled) local node to make the leader perform a full sync to this local node if an HA Raft cluster exists. If reset is performed on the leader node, the node will step down from leadership and it will be synced by the next leader node. An HA Raft member will change role to disabled if ncs.conf has incompatible changes to the ncs.conf on the leader; a member will also change role to disabled if there are non-recoverable failures upon opening a snapshot.See the /ha-raft/status/disable-reason leaf for the reason.Set force to true to override reset when /ha-raft/status/role is not set to disabled. |
handover | Handover leadership to another member of the HA Raft cluster or step down from leadership and start a new election. |
read-only | Toggle read-only mode. If the mode is true no configuration changes can occur. |
-
-
-
-The command `show ha-raft` is used in NSO to display the current state of the HA Raft cluster. The output typically includes the following information:
-
-* The role of the local node (for example, whether it is the `leader`, `follower`, `candidate`, or `stalled`).
-* The leader of the cluster, if one has been elected.
-* The list of member nodes that belong to the HA Raft cluster.
-* The connected nodes, which are the nodes with which the local node currently has active RAFT communication.
-* The local node information, detailing the node’s name and status.
-
-This command is useful for both verifying that the HA Raft cluster is set up correctly and for troubleshooting issues by checking the connectivity and role assignments of the nodes. Some noteworthy terms of output are defined in the table below.
-
-
-
-
-
-In case you get an error, such as the `Error: NSO can't reach member node 'ncsd@ADDRESS'.`, please verify all of the following:
-
-* The node at the `ADDRESS` is reachable. You can use the `ping` `ADDRESS` command, for example.
-* The problematic node has the correct `ncs.conf` configuration, especially `cluster-name` and `node-address`. The latter should match the `ADDRESS` and should contain at least one dot.
-* Nodes use compatible configuration. For example, make sure the `ncs.crypto_keys` file (if used) or the `encrypted-strings` configuration in `ncs.conf` is identical across nodes.
-* HA Raft is enabled, using the `show ha-raft` command on the unreachable node.
-* The firewall configuration on the OS and on the network level permits traffic on the required ports (see [Network and `ncs.conf` Prerequisites](high-availability.md#ch_ha.raft_ports)).
-* The node uses a certificate that the CA can validate. For example, copy the certificates to the same location and run `openssl verify -CAfile CA_CERT NODE_CERT` to verify this.
-* Verify the `epmd -names` command on each node shows the ncsd process. If not, stop NSO, run `epmd -kill`, and then start NSO again.
-
-In addition to the above, you may also examine the `logs/raft.log` file for detailed information on the error message and overall operation of the Raft algorithm. The amount of information in the file is controlled by the `/ncs-config/logs/raft-log` configuration in the `ncs.conf`.
-
-### Cluster Management
-
-After the initial cluster setup, you can add new nodes or remove existing nodes from the cluster with the help of the `ha-raft adjust-membership` action. For example:
-
-```bash
-admin@ncs# show ha-raft status member
-ha-raft status member [ ash.example.org birch.example.org cedar.example.org ]
-admin@ncs# ha-raft adjust-membership remove-node birch.example.org
-admin@ncs# show ha-raft status member
-ha-raft status member [ ash.example.org cedar.example.org ]
-admin@ncs# ha-raft adjust-membership add-node dollartree.example.org
-admin@ncs# show ha-raft status member
-ha-raft status member [ ash.example.org cedar.example.org dollartree.example.org ]
-```
-
-When removing nodes using the `ha-raft adjust-membership remove-node` command, the removed node is not made aware that it is removed from the cluster and continues signaling the other nodes. This is a limitation in the algorithm, as it must also handle situations, where the removed node is down or unreachable. To prevent further communication with the cluster, it is important you ensure the removed node is shut down. You should shut down the to-be-removed node prior to removal from the cluster, or immediately after it. The former is recommended but the latter is required if there are only two nodes left in the cluster and shutting down prior to removal would prevent the cluster from reaching consensus.
-
-Additionally, you can force an existing follower node to perform a full re-sync from the leader by invoking the `ha-raft reset` action with the `force` option. Using this action on the leader will make the node give up the leader role and perform a sync with the newly elected leader.
-
-As leader selection during the Raft election is not deterministic, NSO provides the `ha-raft handover` action, which allows you to either trigger a new election if called with no arguments or transfer leadership to a specific node. The latter is especially useful when, for example, one of the nodes resides in a different location and more traffic between locations may incur extra costs or additional latency, so you prefer this node is not the leader under normal conditions.
-
-#### Passive Follower
-
-In certain situations, it may be advantageous to have a follower node that cannot be promoted to leader role. Consider a scenario with three Raft-enabled nodes distributed across two different data centers.
-
-In this case, a node located without a peer in the same data center might experience increased latency due to the requirement for acknowledgments from at least one node in the other data center.
-
-To address this, HA Raft provides the `/ncs-config/ha-raft/passive` setting. When this setting is enabled (set to `true`), it prevents the node from assuming the candidate or leader role. A passive follower still participates by voting in leader elections.
-
-Note that the `passive` parameter is local to the node, meaning other nodes in the cluster are unaware that a particular follower is passive. Consequently, it is possible to initiate a handover action targeting the passive node, but the handover will ultimately fail at a later stage, allowing the current leader to retain its position.
-
-### Migrating From Existing Rule-based HA
-
-If you have an existing HA cluster using the rule-based built-in HA, you can migrate it to use HA Raft instead. This procedure is performed in four distinct high-level steps:
-
-* Ensuring the existing cluster meets migration prerequisites.
-* Preparing the required HA Raft configuration files.
-* Switching to HA Raft.
-* Adding additional nodes to the cluster.
-
-The procedure does not perform an NSO version upgrade, so the cluster remains on the same version. It also does not perform any schema upgrades, it only changes the type of the HA cluster.
-
-The migration procedure is in place, that is, the existing nodes are disconnected from the old cluster and connected to the new one. This results in a temporary disruption of the service, so it should be performed during a service window.
-
-First, you should ensure the cluster meets migration prerequisites. The cluster must use:
-
-* NSO 6.1.2 or later
-* tailf-hcc 6.0 or later (if used)
-
-In case these prerequisites are not met, follow the standard upgrade procedures to upgrade the existing cluster to supported versions first.
-
-Additionally, ensure that all used packages are compatible with HA Raft, as NSO uses some new or updated notifications about HA state changes. Also, verify the network supports the new cluster communications (see [Network and `ncs.conf` Prerequisites](high-availability.md#ch_ha.raft_ports)).
-
-Secondly, prepare all the `ncs.conf` and related files for each node, such as certificates and keys. Create a copy of all the `ncs.conf` files and disable or remove the existing `>ha<` section in the copies. Then add the required configuration items to the copies, as described in [Initial Cluster Setup](high-availability.md#ch_ha.raft_setup) and [Node Names and Certificates](high-availability.md#ch_ha.raft_names). Do not update the `ncs.conf` files used by the nodes yet.
-
-It is recommended but not necessary that you set the seed nodes in `ncs.conf` to the designated primary and fail-over primary. Do this for all `ncs.conf` files for all nodes.
-
-#### Procedure 1. Migration to HA Raft
-
-1. With the new configurations at hand and verified, start the switch to HA Raft. The cluster nodes should be in their nominal, designated roles. If not, perform a failover first.
-2. On the designated (actual) primary, called `node1`, enable read-only mode.
-
- ```bash
- admin@node1# high-availability read-only mode true
- ```
-3. Then take a backup of all nodes.
-4. Once the backup successfully completes, stop the designated fail-over primary (actual secondary) NSO process, update its `ncs.conf` and the related (certificate) files for HA Raft, and then start it again. Connect to this node's CLI, here called node2, and verify HA Raft is enabled with the `show` `ha-raft` command.
-
- ```bash
- admin@node2# show ha-raft
- ha-raft status role stalled
- ha-raft status local-node node2.example.org
- > ... output omitted ... <
- ```
-5. Now repeat the same for the designated primary (`node1`). If you have set the seed nodes, you should see the fail-over primary show under `connected-node`.
-
- ```bash
- admin@node1# show ha-raft
- ha-raft status role stalled
- ha-raft status connected-node [ node2.example.org ]
- ha-raft status local-node node1.example.org
- > ... output omitted ... <
- ```
-6. On the old designated primary (node1) invoke the `ha-raft create-cluster` action and create a two-node Raft cluster with the old fail-over primary (`node2`, actual secondary). The action takes a list of nodes identified by their names. If you have configured `seed-nodes`, you will get auto-completion support, otherwise you have to type in the name of the node yourself.
-
- ```bash
- admin@node1# ha-raft create-cluster member [ node2.example.org ]
- admin@node1# show ha-raft
- ha-raft status role leader
- ha-raft status leader node1.example.org
- ha-raft status member [ node1.example.org node2.example.org ]
- ha-raft status connected-node [ node2.example.org ]
- ha-raft status local-node node1.example.org
- > ... output omitted ... <
- ```
-
- In case of errors running the action, refer to [Initial Cluster Setup](high-availability.md#ch_ha.raft_setup) for possible causes and troubleshooting steps.
-7. Raft requires at least three nodes to operate effectively (as described in [NSO HA Raft](high-availability.md#ug.ha.raft)) and currently, there are only two in the cluster. If the initial cluster had only two nodes, you must provision an additional node and set it up for HA Raft. If the cluster initially had three nodes, there is the remaining secondary node, `node3`, which you must stop, update its configuration as you did with the other two nodes, and start it up again.
-8. Finally, on the old designated primary and current HA Raft leader, use the `ha-raft adjust-membership add-node` action to add this third node to the cluster.
-
- ```bash
- admin@node1# ha-raft adjust-membership add-node node3.example.org
- admin@node1# show ha-raft status member
- ha-raft status member [ node1.example.org node2.example.org node3.example.org ]
- ```
-
-### Security Considerations
-
-Communication between the NSO nodes in an HA Raft cluster takes place over Distributed Erlang, an RPC protocol transported over TLS (unless explicitly disabled by setting `/ncs-config/ha-raft/ssl/enabled` to 'false').
-
-TLS (Transport Layer Security) provides Authentication and Privacy by only allowing NSO nodes to connect using certificates and keys issued from the same Certificate Authority (CA). Distributed Erlang is transported over TLS 1.2. Access to a host can be revoked by the CA through the means of a CRL (Certificate Revocation List). To enforce certificate revocation within an HA Raft cluster, invoke the action /ha-raft/disconnect to terminate the pre-existing connection. A connection to the node can re-establish once the node's certificate is valid.
-
-Please ensure the CA key is kept in a safe place since it can be used to generate new certificates and key pairs for peers.
-
-Distributed Erlang supports for multiple NSO nodes to run on the same host and the node addresses are resolved by the `epmd` ([Erlang Port Mapper Daemon](https://www.erlang.org/resources/man/epmd.html)) service. Once resolved, the NSO nodes communicate directly.
-
-The ports `epmd` and the NSO nodes listen to can be found in [Network and `ncs.conf` Prerequisites](high-availability.md#ch_ha.raft_ports). `epmd` binds the wildcard IPv4 address `0.0.0.0` and the IPv6 address `::`.
-
-In case `epmd` is exposed to a DoS attack, the HA Raft members may be unable to resolve addresses and communication could be disrupted. Please ensure traffic on these ports are only accepted between the HA Raft members by using firewall rules or other means.
-
-Two NSO nodes can only establish a connection if a shared secret "cookie" matches. The cookie is optionally configured from `/ncs-config/ha-raft/cluster-name`. Please note the cookie is not a security feature but a way to isolate HA Raft clusters and to avoid accidental misuse.
-
-### Packages Upgrades in Raft Cluster
-
-NSO contains a mechanism for distributing packages to nodes in a Raft cluster, greatly simplifying package management in a highly-available setup.
-
-You perform all package management operations on the current leader node. To identify the leader node, you can use the `show ha-raft status leader` command on a running cluster.
-
-Invoking the `packages reload` command makes the leader node update its currently loaded packages, identical to a non-HA, single-node setup. At the same time, the leader also distributes these packages to the followers to load. However, the load paths on the follower nodes, such as `/var/opt/ncs/packages/`, are not updated. This means, that if a leader election took place, a different leader was elected, and you performed another `packages reload`, the system would try to load the versions of the packages on this other leader, which may be out of date or not even present.
-
-The recommended approach is, therefore, to use the `packages ha sync and-reload` command instead, unless a load path is shared between NSO nodes, such as the same network drive. This command distributes and updates packages in the load paths on the follower nodes, as well as loading them.
-
-For the full procedure, first, ensure all cluster nodes are up and operational, then follow these steps on the leader node:
-
-* Perform a full backup of the NSO instance, such as running `ncs-backup`.
-* Add, replace, or remove packages on the filesystem. The exact location depends on the type of NSO deployment, for example `/var/opt/ncs/packages/`.
-* Invoke the `packages ha sync and-reload` or `packages ha sync and-add` command to start the upgrade process.
-
-Note that while the upgrade is in progress, writes to the CDB are not allowed and will be rejected.
-
-For a `packages ha sync and-reload` example see the `raft-upgrade-l2` NSO system installation-based example referenced by the [examples.ncs/high-availability/hcc](https://github.com/NSO-developer/nso-examples/tree/6.6/high-availability/hcc) example in the NSO example set.
-
-For more details, troubleshooting, and general upgrade recommendations, see [NSO Packages](package-mgmt.md) and [Upgrade](../installation-and-deployment/upgrade-nso.md).
-
-### Version Upgrade of Cluster Nodes
-
-Currently, the only supported and safe way of upgrading the Raft HA cluster NSO version requires that the cluster be taken offline since the nodes must, at all times, run the same software version.
-
-Do not attempt an upgrade unless all cluster member nodes are up and actively participating in the cluster. Verify the current cluster state with the `show ha-raft status` command. All member nodes must also be present in the connected-node list.
-
-The procedure differentiates between the current leader node versus followers. To identify the leader, you can use the `show ha-raft status leader` command on a running cluster.
-
-**Procedure 2. Cluster Version Upgrade**
-
-1. On the leader, first enable read-only mode using the `ha-raft read-only mode true` command and then verify that all cluster nodes are in sync with the `show ha-raft status log replications state` command.
-2. Before embarking on the upgrade procedure, it's imperative to backup each node. This ensures that you have a safety net in case of any unforeseen issues. For example, you can use the `$NCS_DIR/bin/ncs-backup` command.
-3. Delete the `$NCS_RUN_DIR/cdb/compact.lock` file and compact the CDB write log on all nodes using, for example, the `$NCS_DIR/bin/ncs --cdb-compact $NCS_RUN_DIR/cdb` command.
-4. On all nodes, delete the `$NCS_RUN_DIR/state/raft/` directory with a command such as `rm -rf $NCS_RUN_DIR/state/raft/`.
-5. Stop NSO on all the follower nodes, for example, invoking the `$NCS_DIR/bin/ncs --stop` or `systemctl stop ncs` command on each node.
-6. Stop NSO on the leader node only after you have stopped all the follower nodes in the previous step. Alternatively NSO can be stopped on the nodes before deleting the HA Raft state and compacting the CDB write log without needing to delete the `compact.lock` file.
-7. Upgrade the NSO packages on the leader to support the new NSO version.
-8. Install the new NSO version on all nodes.
-9. Start NSO on all nodes.
-10. Re-initialize the HA cluster using the `ha-raft create-cluster` action on the node to become the leader.
-11. Finally, verify the cluster's state through the `show ha-raft status` command. Ensure that all data has been correctly synchronized across all cluster nodes and that the leader is no longer read-only. The latter happens automatically after re-initializing the HA cluster.
-
-For a standard System Install, the single-node procedure is described in [Single Instance Upgrade](../installation-and-deployment/upgrade-nso.md#ug.admin_guide.manual_upgrade), but in general depends on the NSO deployment type. For example, it will be different for containerized environments. For specifics, please refer to the documentation for the deployment type.
-
-For an example see the `raft-upgrade-l2` NSO system installation-based example referenced by the [examples.ncs/high-availability/hcc](https://github.com/NSO-developer/nso-examples/tree/6.6/high-availability/hcc) example in the NSO example set.
-
-If the upgrade fails before or during the upgrade of the original leader, start up the original followers to restore service and then restore the original leader, using backup as necessary.
-
-However, if the upgrade fails after the original leader was successfully upgraded, you should still be able to complete the cluster upgrade. If you are unable to upgrade a follower node, you may provision a (fresh) replacement and the data and packages in use will be copied from the leader.
-
-## NSO Rule-based HA
-
-NSO can manage the HA groups based on a set of predefined rules. This functionality was added in NSO 5.4 and is sometimes referred to simply as the built-in HA. However, since NSO 6.1, HA Raft (which is also built-in) is available as well, and is likely a better choice in most situations.
-
-Rule-based HA allows administrators to:
-
-* Configure HA group members with IP addresses and default roles
-* Configure failover behavior
-* Configure start-up behavior
-* Configure HA group members with IP addresses and default roles
-* Assign roles, join HA group, enable/disable rule-based HA through actions
-* View the state of the current HA setup
-
-NSO rule-based HA is defined in `tailf-ncs-high-availability.yang`, with data residing under the `/high-availability/` container.
-
-{% hint style="info" %}
-In environments with high NETCONF traffic, particularly when using `ncs_device_notifs`, it's recommended to enable read-only mode on the designated primary node before performing HA activation or sync. This prevents `app_sync` from being blocked by notification processing.
-
-Use the following command prior to enabling HA or assigning roles:
-
-```bash
-admin@ncs# high-availability read-only mode true
-```
-
-After successful sync and HA establishment, disable read-only mode:
-
-```bash
-admin@ncs# high-availability read-only mode false
-```
-{% endhint %}
-
-NSO rule-based HA does not manage any virtual IP addresses, or advertise any BGP routes or similar. This must be handled by an external package. Tail-f HCC 5.x and greater has this functionality compatible with NSO rule-based HA. You can read more about the HCC package in the [following chapter](high-availability.md#ug.ha.hcc).
-
-### Prerequisites
-
-To use NSO rule-based HA, HA must first be enabled in `ncs.conf` - See [Mode of Operation](high-availability.md#ha.moo).
-
-{% hint style="info" %}
-If the package tailf-hcc with a version less than 5.0 is loaded, NSO rule-based HA will not function. These HCC versions may still be used but NSO built-in HA will not function in parallel.
-{% endhint %}
-
-### HA Member Configuration
-
-All HA group members are defined under `/high-availability/ha-node`. Each configured node must have a unique IP address configured and a unique HA ID. Additionally, nominal roles and fail-over settings may be configured on a per-node basis.
-
-The HA Node ID is a unique identifier used to identify NSO instances in an HA group. The HA ID of the local node - relevant amongst others when an action is called - is determined by matching configured HA node IP addresses against IP addresses assigned to the host machine of the NSO instance. As the HA ID is crucial to NSO HA, NSO rule-based HA will not function if the local node cannot be identified.
-
-To join a HA group, a shared secret must be configured on the active primary and any prospective secondary. This is used for a CHAP-2-like authentication and is specified under `/high-availability/token/`.
-
-{% hint style="info" %}
-In an NSO System Install setup, not only does the shared token need to match between the HA group nodes but the configuration for encrypted strings, default stored in `/etc/ncs/ncs.crypto_keys`, need also to match between the nodes in the HA group.
-{% endhint %}
-
-The token configured on the secondary node is overwritten with the encrypted token of type `aes-256-cfb-128-encrypted-string` from the primary node when the secondary node connects to the primary. If there is a mismatch between the encrypted-string configuration on the nodes, NSO will not decrypt the HA token to match the token presented. As a result, the primary node denies the secondary node access the next time the HA connection needs to reestablish with a "Token mismatch, secondary is not allowed" error.
-
-See the `upgrade-l2` example, referenced from [examples.ncs/high-availability/hcc](https://github.com/NSO-developer/nso-examples/tree/6.6/high-availability/hcc), for an example setup and the [Deployment Example](../installation-and-deployment/deployment/deployment-example.md) for a description of the example.
-
-Also, note that the `ncs.crypto_keys` file is highly sensitive. The file contains the encryption keys for all CDB data that is encrypted on disk. Besides the HA token, this often includes passwords for various entities, such as login credentials to managed devices.
-
-### HA Roles
-
-NSO can assume HA roles `primary`, `secondary` and `none`. Roles can be assigned directly through actions, or at startup or failover. See [HA Framework Requirements](high-availability.md#ferret) for the definition of these roles.
-
-{% hint style="info" %}
-NSO rule-based HA does not support relay-secondaries.
-{% endhint %}
-
-NSO rule-based HA distinguishes between the concepts of nominal role and assigned role. Nominal-role is configuration data that applies when an NSO instance starts up and at failover. The assigned role is the role that the NSO instance has been ordered to assume either by an action or as a result of startup or failover.
-
-### Failover
-
-Failover may occur when a secondary node loses the connection to the primary node. A secondary may then take over the primary role. Failover behavior is configurable and controlled by the parameters:
-
-* `/high-availability/ha-node{id}/failover-primary`
-* `/high-availability/settings/enable-failover`
-
-For automatic failover to function, `/high-availability/settings/enable-failover` must be se to `true`. It is then possible to enable at most one node with a nominal role secondary as failover-primary, by setting the parameter `/high-availability/ha-node{id}/failover-primary`. The failover works in both directions; if a nominal primary is currently connected to the failover-primary as a secondary and loses the connection, then it will attempt to take over as a primary.
-
-Before failover happens, a failover-primary-enabled secondary node may attempt to reconnect to the previous primary before assuming the primary role. This behavior is configured by the parameters denoting how many reconnect attempts will be made, and with which interval, respectively.
-
-* `/high-availability/settings/reconnect-attempts`
-* `/high-availability/settings/reconnect-interval`
-
-HA Members that are assigned as secondaries, but are neither failover-primaries nor set with a nominal-role primary, may attempt to rejoin the HA group after losing connection to the primary.
-
-This is controlled by `/high-availability/settings/reconnect-secondaries`. If this is true, secondary nodes will query the nodes configured under `/high-availability/ha-node` for an NSO instance that currently has the primary role. Any configured nominal roles will not be considered. If no primary node is found, subsequent attempts to rejoin the HA setup will be issued with an interval defined by `/high-availability/settings/reconnect-interval`.
-
-In case a net-split provokes a failover it is possible to end up in a situation with two primaries, both nodes accepting writes. The primaries are then not synchronized and will end up in a split brain. Once one of the primaries joins the other as a secondary, the HA cluster is once again consistent but any out-of-sync changes will be overwritten.
-
-To prevent split-brain from occurring, NSO 5.7 or later comes with a rule-based algorithm. The algorithm is enabled by default, it can be disabled or changed from the parameters:
-
-* `/high-availability/settings/consensus/enabled [true]`
-* `/high-availability/settings/consensus/algorithm [ncs:rule-based]`
-
-The rule-based algorithm can be used in either of the two HA constellations:
-
-* Two nodes: one nominal primary and one nominal secondary configured as failover-primary.
-* Three nodes: one nominal primary, one nominal secondary configured as failover-primary, and one perpetual secondary.
-
-On failover:
-
-* Failover-primary: become primary but enable read-only mode. Once the secondary joins, disable read-only.
-* Nominal primary: on loss of all secondaries, change role to none. If one secondary node is connected, stay primary.
-
-{% hint style="info" %}
-In certain cases, the rule-based consensus algorithm results in nodes being disconnected and will not automatically rejoin the HA cluster, such as in the example above when the nominal primary becomes none on the loss of all secondaries.
-{% endhint %}
-
-To restore the HA cluster one may need to manually invoke the `/high-availability/be-secondary-to` action.
-
-{% hint style="info" %}
-In the case where the failover-primary takes over as primary, it will enable read-only mode, if no secondary connects it will remain read-only. This is done to guarantee consistency.
-{% endhint %}
-
-{% hint style="info" %}
-In a three-node cluster, when the nominal primary takes over as actual primary, it first enables read-only mode and stays in read-only mode until a secondary connects. This is done to guarantee consistency.
-{% endhint %}
-
-The read-write mode can manually be enabled from the `/high-availability/read-only` action with the parameter mode passed with value false.
-
-When any node loses connection, this can also be observed in high-availability alarms as either a `ha-primary-down` or a `ha-secondary-down` alarm.
-
-```bash
-alarms alarm-list alarm ncs ha-primary-down /high-availability/ha-node[id='paris']
- is-cleared false
- last-status-change 2022-05-30T10:02:45.706947+00:00
- last-perceived-severity critical
- last-alarm-text "Lost connection to primary due to: Primary closed connection"
- status-change 2022-05-30T10:02:45.706947+00:00
- received-time 2022-05-30T10:02:45.706947+00:00
- perceived-severity critical
- alarm-text "Lost connection to primary due to: Primary closed connection"
-```
-
-```bash
-alarms alarm-list alarm ncs ha-secondary-down /high-availability/ha-node[id='london'] ""
- is-cleared false
- last-status-change 2022-05-30T10:04:33.231808+00:00
- last-perceived-severity critical
- last-alarm-text "Lost connection to secondary"
- status-change 2022-05-30T10:04:33.231808+00:00
- received-time 2022-05-30T10:04:33.231808+00:00
- perceived-severity critical
- alarm-text "Lost connection to secondary"
-```
-
-### Startup
-
-Startup behavior is defined by a combination of the parameters `/high-availability/settings/start-up/assume-nominal-role` and `/high-availability/settings/start-up/join-ha` as well as the node's nominal role:
-
-show ha-raft Field Definitions
-
-The command `show ha-raft` is used in NSO to display the current state of the HA Raft cluster. The output typically includes the following information:
-
-* The role of the local node (for example, whether it is the `leader`, `follower`, `candidate`, or `stalled`).
-* The leader of the cluster, if one has been elected.
-* The list of member nodes that belong to the HA Raft cluster.
-* The connected nodes, which are the nodes with which the local node currently has active RAFT communication.
-* The local node information, detailing the node’s name and status.
-
-This command is useful for both verifying that the HA Raft cluster is set up correctly and for troubleshooting issues by checking the connectivity and role assignments of the nodes. Some noteworthy terms of output are defined in the table below.
-
-| Term | Definition |
|---|---|
role | The current node’s Raft role (leader, follower, or candidate). Occasionally, in NSO, a node might appear as stalled if it has lost contact with the leader or quorum. |
leader | The current known leader of the cluster. |
member | A node that is part of the RAFT consensus group (i.e., a voting participant, not an observer). Leaders, followers, and candidates are members; observers are not. |
connected-node | The nodes this instance is connected to. |
local-node | The name of the current node. |
lag | The number of indices the replicated log is behind the leader node. A value of 0 means no lag — the node's RAFT log is fully up-to-date with the leader. The larger the value, the more out-of-sync the node is, which may indicate a replication or connectivity issue. |
index | The last replicated HA Raft log index, i.e., this is the last log entry replicated to a node. |
state | The synchronization status of the node’s RAFT log. Common values include:
|
current-index | The latest log index on this node. |
applied-index | The last index applied to CDB. |
serial-number | The certificate serial number. Used to uniquely identify the node. |
| assume-nominal-role | join-ha | nominal-role | Behaviour |
|---|---|---|---|
true | false | primary | Assume primary role. |
true | false | secondary | Attempt to connect as secondary to the node (if any), which has nominal-role primary. If this fails, make no retry attempts and assume none role. |
true | false | none | Assume none role |
false | true | primary | Attempt to join HA setup as secondary by querying for the current primary. Retries will be attempted. Retry attempt interval is defined by /high-availability/settings/reconnect-interval. |
false | true | secondary | Attempt to join HA setup as secondary by querying for the current primary. Retries will be attempted. Retry attempt interval is defined by /high-availability/settings/reconnect-interval. If all retry attempts fail, assume none role. |
false | true | none | Assume none role. |
true | true | primary | Query HA setup once for a node with primary role. If found, attempt to connect as secondary to that node. If no current primary is found, assume primary role. |
true | true | secondary | Attempt to join HA setup as secondary by querying for the current primary. Retries will be attempted. Retry attempt interval is defined by /high-availability/settings/reconnect-interval. If all retry attempts fail, assume none role. |
true | true | none | Assume none role. |
false | false | - | Assume none role. |
| Action | Description |
|---|---|
be-primary | Order the local node to assume the HA role primary. |
be-none | Order the local node to assume the HA role none. |
be-secondary-to | Order the local node to connect as secondary to the provided HA node. This is an asynchronous operation; the result can be found under /high-availability/status/be-secondary-result. |
local-node-id | Identify which of the nodes in /high-availability/ha-node (if any) corresponds to the local NSO instance. |
enable | Enable NSO rule-based HA and optionally assume an HA role according to /high-availability/settings/start-up/ parameters. |
disable | Disable NSO rule-based HA and assume a HA role none. |
| Tool | Package | Required | Description |
|---|---|---|---|
ip | iproute2 | yes | Adds and deletes the virtual IP from the network interface. |
awk | mawk or gawk | yes | Installed with most Linux distributions. |
sed | sed | yes | Installed with most Linux distributions. |
arping | iputils or arping | optional | Installation recommended. Will reduce the propagation of changes to the virtual IP for layer-2 configurations. |
gobgpd and gobgp | GoBGP 2.x | optional | Required for layer-3 configurations. gobgpd is started by the HCC package and advertises the virtual IP using BGP. gobgp is used to get advertised routes. |
nsupdate | bind-tools or knot-dnsutils | optional | Required for layer-3 DNS update functionality and is used to submit Dynamic DNS Update requests to a name server. |
| Parameters | Type | Description |
|---|---|---|
enabled | boolean | If set to 'true', the primary node in an HA group automatically binds the set of Virtual IPv[46] addresses. |
vip-address | list of inet:ip-address | The list of virtual IPv[46] addresses to bind on the primary node. The addresses are automatically unbound when a node becomes secondary. The addresses can therefore be used externally to reliably connect to the HA group primary node. |
| Parameters | Type | Description |
|---|---|---|
node-id | string | Unique node ID. A reference to /ncs:high-availability/ha-node/id. |
enabled | boolean | If set to true, this node uses BGP to announce VIP addresses when in the HA primary state. |
as | inet:as-number | The BGP Autonomous System Number for the local BGP daemon. |
router-id | inet:ip-address | The router ID for the local BGP daemon. |
| Parameters | Type | Description |
|---|---|---|
address | inet:ip-address | BGP neighbor IP address. |
as | inet:as-number | BGP neighbor Autonomous System Number. |
ttl-min | uint8 | Optional minimum TTL value for BGP packets. When configured, enables BGP Generalized TTL Security Mechanism (GTSM). |
password | string | Optional password to use for BGP authentication with this neighbor. |
enabled | boolean | If set to true, then an outgoing BGP connection to this neighbor is established by the HA group primary node. |
| Parameters | Type | Description |
|---|---|---|
enabled | boolean | If set to true, DNS updates will be enabled. |
fqdn | inet:domain-name | DNS domain-name for the HA primary. |
ttl | uint32 | Time to live for DNS record, default 86400. |
key-file | string | Specifies the file path for nsupdate keyfile. |
server | inet:ip-address | DNS Server IP Address. |
port | uint32 | DNS Server port, default 53. |
zone | inet:host | DNS Zone to update on the server. |
timeout | uint32 | Timeout for nsupdate command, default 300. |
| Parameter | Type | Description |
|---|---|---|
node-id | string | Unique NSO HA node ID. Valid values are: /high-availability/ha-node when built-in HA is used or /ha-raft/status/member for HA Raft. |
ip-address | inet:ip-address | IP where NSO listens for incoming requests to any northbound interfaces. |
location | string | Name of the Location/Site/Availability-Zone where node is placed. |
| Hostname | Address | Role |
|---|---|---|
paris | 192.168.23.99 | Paris service node. |
london | 192.168.23.98 | London service node. |
vip4 | 192.168.23.122 | NSO primary node IPv4 VIP address. |
| Hostname | Address | AS | Role |
|---|---|---|---|
paris | 192.168.31.99 | 64512 | Paris node |
london | 192.168.30.98 | 64513 | London node |
router | 192.168.30.2 192.168.31.2 | 64514 | BGP-enabled router |
vip4 | 192.168.23.122 | Primary node IPv4 VIP address |
Load Balancer Routes Connections to the Appropriate NSO Node
Load Balancer Uses Health Checks to Determine the Currently Active Primary Node
-
-
-
-YANG Data Model
- -The NED provides a YANG data model of the device to NSO and services, enabling standardized configuration management. This applies only to NEDs where Cisco creates and maintains the device data model—commonly referred to as classic NEDs, which includes both the CLI-based and Generic NEDs—and excludes third-party YANG (3PY) NEDs, where the model is provided externally.\ -\ -Note that for classic NEDs, the device model is typically implemented as a superset, covering multiple versions or variants of a given device type. This approach allows a single NED package to support a broad range of software versions or hardware flavors. The benefit is simplified deployment and upgrade handling across similar devices. However, a side effect is that certain parts of the model may not apply to the specific device instance in use. - -
-
-
-
-NSO ensures all data modifications occur within a single transaction for consistency and guarantees a transaction is either completely successful or fails, maintaining data integrity.
-
-#### **What a NED Does not Provide**
-
-Data Translation
- -The NED is responsible for transforming outbound data from NSO's internal format into a format understood by the device — whether that format is vendor-specific (e.g., CLI, REST, SOAP) or standards-based (e.g., NETCONF, RESTCONF, gNMI). It also handles the reverse transformation for inbound data from the device back into NSO's format. - -
-
-
-
-A Data Model of the Entire Set in the Data
- -For Classic NEDs, NED development is use-case driven. As a result, a NED, in most cases, does not contain the complete data model of a device. Providing a 100% complete YANG model for a device is not a goal and is not in the scope of NED development. It does not make sense to invest resources into modeling data which is not needed to support the desired use cases. If a NED does not cover a needed use case, please submit an enhancement request via your support channel. For third party NEDs, the models come from third party sources not controlled by Cisco. - -
-
-
-
-An Exact Copy of the Syntax in the Device CLI
- -NED development focuses on representing device data for NSO. As a side effect for CLI NEDs, the NSO CLI will get similar behavior as the device CLI, however, in most situations, this will not be perfect and is not the goal of the NED. - -
-
-
-
-Fine-grained Validation of Data (Classic NEDs Only)
- -In classic NEDs, adding strict validations in the YANG model (e.g., `mandatory`, `when`, `must`, `range`, `min`, `max`, etc.) can lead to inflexible models. These constraints are interpreted and enforced by NSO at runtime, not the device. Since such validations often need to be updated as devices evolve across versions, NSO's policy is to keep the models relaxed by minimizing the use of these validation constructs. This allows for greater flexibility and forward compatibility. - -
-
-
-
-Convenience Macros in the Device CLI (Only Discrete Data Leaves are Supported)
- -Some devices have macro-style functionality in the CLI and users may find it annoying that these are not available in NEDs. The convenience macros have proven very dynamic in the parameters they change, causing frequent out-of-sync situations, but these are generally not available in the NED. - -
-
-
-
-Dynamic Configuration in Devices (Only Data in a Transaction May Change)
- -Cisco NEDs do not model device-generated or dynamic configuration, as such behavior varies between device versions and is difficult to standardize. Only configuration explicitly included in a transaction is managed by NSO. If needed, service logic can insert expected dynamic elements during provisioning. - -
-
-
-
-Auto-correction of Parameters with Multiple Syntaxes (i.e., Use Canonical Form)
- -The NED does not allow the same value for a parameter to have a different name (e.g., `true` vs. `yes`). The canonical name displayed in `show-running-config` or similar is used. - -
-
-
-
-Handling Out-of-band Changes (Model as Operational Data)
- -Leaves that have out-of-band changes will cause NSO and the device to become out- of-sync, and should be made "config false", or not be part of the model at all. Similarly, actions that cause out-of-band changes are not supported. - -
-
-
-
-Splitting a Single Transaction into Several Sub-transactions
- -For devices that support the transaction paradigm, the NED will never split an NSO transaction in two or more device transactions. The service must handle this by doing multiple NSO transactions. - -
-
-
-
-## Types of NED Packages
-
-A NED package is a package that NSO uses to manage a particular type of device. A NED is a piece of code that enables communication with a particular type of managed device. You add NEDs to NSO as a special kind of package, called NED packages.
-
-A NED package must provide a device YANG model as well as define means (protocol) to communicate with the device. The latter can either leverage the NSO built-in NETCONF and SNMP support or use a custom implementation. When a package provides custom protocol implementation, typically written in Java, it is called a CLI NED or a Generic NED.
-
-Cisco provides and supports a number of such NEDs. With these Cisco-provided NEDs, a major category are CLI NEDs which communicate with a device through its CLI instead of a dedicated API.
-
-Backporting of Fixes to Old NED Releases (i.e., Trunk based Development is Used)
- -All NEDs use trunk-based development, i.e., new NED releases are created from the tip of a single branch, develop. New features and fixes are thus delivered to the stakeholders in the latest NED release, not by backporting an old release. - -
NED Package Types
| NED Category | Purpose | Provider | YANG Model Provider | YANG Models Included? | Device Interface | Protocols Supported | Key Characteristics |
|---|---|---|---|---|---|---|---|
| CLI NED* | Designed for devices with a CLI-based interface. The NED parses CLI commands and translates data to/from YANG. | Cisco | Cisco NSO NED Team | Yes | CLI (Command Line Interface) | SSH, Telnet |
|
| Generic NED - Cisco YANG Models* | Built for API-based devices (e.g., REST, SOAP, TL1), using custom parsers and data transformation logic maintained by Cisco. | Cisco | Cisco NSO NED Team | Yes | Non-CLI (API-based) | REST, TL1, CORBA, SOAP, RESTCONF, gNMI, NETCONF |
|
| Third-party YANG NED | Cisco-supplied generic NED packages that do not include any device models. | Cisco | Third-party Vendors/Organizations (IETF, IEEE, ONF, OpenConfig) | No - Must be downloaded separately | Model-driven protocols | NETCONF, RESTCONF, gNMI |
|
CLI NED
Generic NED
Third-Party YANG NEDs
| Recipe Type | Purpose | Description |
|---|---|---|
| Download Recipes (DR) | YANG Model Sourcing |
|
| YANG Recipes (YR) | YANG File Fixes |
|
| Runtime Recipes (RR) | Device Behavior Fixes |
|
NED Version Scheme
Sample NED Package Versioning
Side by Side, Running Config on the Left, Template on the Right.
daemon-status | You can see the NSO daemon mode, starting, phase0, phase1, started, stopping. The phase0 and phase1 modes are schema upgrade modes and will appear if you have upgraded any data models. |
version | The NSO version. |
smp | Number of threads used by the daemon. |
ha | The High-Availability mode of the NCS daemon will show up here: secondary, primary, relay-secondary. |
internal/callpoints | The next section is callpoints. Make sure that any validation points, etc. are registered. (The
Of special interest is of course the |
internal/cdb | The cdb section is important. Look for any locks. This might be a sign that a developer has taken a CDB lock without releasing it. The subscriber section is also important. A design pattern is to register subscribers to wait for something to change in NSO and then trigger an action. Reactive FASTMAP is designed around that. Validate that all expected subscribers are OK. |
loaded-data-models | The next section shows all namespaces and YANG modules that are loaded. If you, for example, are missing a service model, make sure it is loaded. |
cli, netconf, rest, snmp, webui | All northbound agents like CLI, REST, NETCONF, SNMP, etc. are listed with their IP and port. So if you want to connect over REST, for example, you can see the port number here. |
patches | Lists any installed patches. |
upgrade-mode | If the node is in upgrade mode, it is not possible to get any information from the system over NETCONF. Existing CLI sessions can get system information. |
-
-
-
-Installation Problems: Error Messages During Installation
- -* **Error** - - ``` - tar: Skipping to next header - gzip: stdin: invalid compressed data--format violated - ``` - -- **Impact**\ - The resulting installation is incomplete. - -* **Cause**\ - This happens if the installation program has been damaged, most likely because it has been downloaded in ASCII mode. - -- **Resolution**\ - Remove the installation directory. Download a new copy of NSO from our servers. Make sure you use binary transfer mode every step of the way. - -
-
-
-
-Problem Starting NSO: NSO Terminating with GLIBC Error
- -* **Error** - - ``` - Internal error: Open failed: /lib/tls/libc.so.6: version - `GLIBC_2.3.4' not found (required by - .../lib/ncs/priv/util/syst_drv.so) - ``` - -- **Impact**\ - NSO terminates immediately with a message similar to the one above. - -* **Cause**\ - This happens if you are running on a very old Linux version. The GNU libc (GLIBC) version is older than 2.3.4, which was released in 2004. - -- **Resolution**\ - Use a newer Linux system, or upgrade the GLIBC installation. - -
-
-Problem in Running Examples: The
-
-* **Error**\
- You must install the Python SSH implementation Paramiko in order to use SSH.
-
-- **Impact**\
- Sending NETCONF commands and queries with `netconf-console` fails, while it works using `netconf-console-tcp`.
-
-* **Cause**\
- The `netconf-console` command is implemented using the Python programming language. It depends on the Python SSHv2 implementation Paramiko. Since you are seeing this message, your operating system doesn't have the Python module Paramiko installed.
-
-- **Resolution**\
- Install Paramiko using the instructions from [https://www.paramiko.org](https://www.paramiko.org/).\
- \
- When properly installed, you will be able to import the Paramiko module without error messages.
-
- ```bash
- $ python
- ...
- >>> import paramiko
- >>>
- ```
-
- \
- Exit the Python interpreter with Ctrl+D.
-
-* **Workaround**\
- A workaround is to use `netconf-console-tcp`. It uses TCP instead of SSH and doesn't require Paramiko. Note that TCP traffic is not encrypted.
-
-
-
-Problem in Running Examples: The netconf-console Program Fails
-
-* **Error**\
- You must install the Python SSH implementation Paramiko in order to use SSH.
-
-- **Impact**\
- Sending NETCONF commands and queries with `netconf-console` fails, while it works using `netconf-console-tcp`.
-
-* **Cause**\
- The `netconf-console` command is implemented using the Python programming language. It depends on the Python SSHv2 implementation Paramiko. Since you are seeing this message, your operating system doesn't have the Python module Paramiko installed.
-
-- **Resolution**\
- Install Paramiko using the instructions from [https://www.paramiko.org](https://www.paramiko.org/).\
- \
- When properly installed, you will be able to import the Paramiko module without error messages.
-
- ```bash
- $ python
- ...
- >>> import paramiko
- >>>
- ```
-
- \
- Exit the Python interpreter with Ctrl+D.
-
-* **Workaround**\
- A workaround is to use `netconf-console-tcp`. It uses TCP instead of SSH and doesn't require Paramiko. Note that TCP traffic is not encrypted.
-
-
-
-
-
-### General Troubleshooting Strategies
-
-If you have trouble starting or running NSO, examples, or the clients you write, here are some troubleshooting tips.
-
-Problems Using and Developing Services
- -If you encounter issues while loading service packages, creating service instances, or developing service models, templates, and code, you can consult the Troubleshooting section in [Implementing Services](../../../development/core-concepts/implementing-services.md). - -
-
-
-
-Transcript
- -When contacting support, it often helps the support engineer to understand what you are trying to achieve if you copy-paste the commands, responses, and shell scripts that you used to trigger the problem, together with any CLI outputs and logs produced by NSO. - -
-
-
-
-Source ENV Variables
- -If you have problems executing `ncs` commands, make sure you source the `ncsrc` script in your NSO directory (your path may be different than the one in the example if you are using a local install), which sets the required environmental variables. - -```bash -$ source /etc/profile.d/ncs.sh -``` - -
-
-
-
-Log Files
- -To find out what NSO is/was doing, browsing NSO log files is often helpful. In the examples, they are called `devel.log`, `ncs.log`, `audit.log`. If you are working with your own system, make sure that the log files are enabled in `ncs.conf`. They are already enabled in all the examples. You can read more about how to enable and inspect various logs in the [Logging](./#ug.ncs_sys_mgmt.logging) section. - -
-
-
-
-Verify HW Resources
- -Both high CPU utilization and a lack of memory can negatively affect the performance of NSO. You can use commands such as `top` to examine resource utilization, and `free -mh` to see the amount of free and consumed memory. A common symptom of a lack of memory is NSO or Java-VM restarting. A sufficient amount of disk space is also required for CDB persistence and logs, so you can also check disk space with `df -h` command. In case there is enough space on the disk and you still encounter ENOSPC errors, check the inode usage with `df -i` command. - -
-
-
-
-Status
- -NSO will give you a comprehensive status of daemon status, YANG modules, loaded packages, MIBs, active user sessions, CDB locks, and more if you run: - -```bash -$ ncs --status -``` - -NSO status information is also available as operational data under `/ncs-state`. - -
-
-
-
-Check Data Provider
- -If you are implementing a data provider (for operational or configuration data), you can verify that it works for all possible data items using: - -```bash -$ ncs --check-callbacks -``` - -
-
-
-
-Debug Dump
- -If you suspect you have experienced a bug in NSO, or NSO told you so, you can give Support a debug dump to help us diagnose the problem. It contains a lot of status information (including a full `ncs --status report`) and some internal state information. This information is only readable and comprehensible to the NSO development team, so send the dump to your support contact. A debug dump is created using: - -```bash -$ ncs --debug-dump mydump1 -``` - -Just as in CSI on TV, the information must be collected as soon as possible after the event. Many interesting traces will wash away with time, or stay undetected if there are lots of irrelevant facts in the dump. - -If NSO gets stuck while terminating, it can optionally create a debug dump after being stuck for 60 seconds. To enable this mechanism, set the environment variable `$NCS_DEBUG_DUMP_NAME` to a filename of your choice. - -
-
-
-
-Error Log
- -Another thing you can do in case you suspect that you have experienced a bug in NSO is to collect the error log. The logged information is only readable and comprehensible to the NSO development team, so send the log to your support contact. The log actually consists of a number of files called `ncserr.log.*` - make sure to provide them all. - -
-
-
-
-System Dump
- -If NSO aborts due to failure to allocate memory (see [Disaster Management](./#ug.ncs_sys_mgmt.disaster)), and you believe that this is due to a memory leak in NSO, creating one or more debug dumps as described above (before NSO aborts) will produce the most useful information for Support. If this is not possible, NSO will produce a system dump by default before aborting, unless `DISABLE_NCS_DUMP` is set. - -The default system dump file name is `ncs_crash.dump` and it could be changed by setting the environment variable `$NCS_DUMP` before starting NSO. The dumped information is only comprehensible to the NSO development team, so send the dump to your support contact. - -
-
-
diff --git a/administration/management/system-management/alarms.md b/administration/management/system-management/alarms.md
deleted file mode 100644
index 82fcb77f..00000000
--- a/administration/management/system-management/alarms.md
+++ /dev/null
@@ -1,693 +0,0 @@
-# Alarm Types
-
-```
-alarm-type
- cdb-offload-threshold-too-low
- certificate-expiration
- ha-alarm
- ha-node-down-alarm
- ha-primary-down
- ha-secondary-down
- ncs-cluster-alarm
- cluster-subscriber-failure
- ncs-dev-manager-alarm
- abort-error
- auto-configure-failed
- commit-through-queue-blocked
- commit-through-queue-failed
- commit-through-queue-failed-transiently
- commit-through-queue-rollback-failed
- configuration-error
- connection-failure
- final-commit-error
- missing-transaction-id
- ned-live-tree-connection-failure
- out-of-sync
- revision-error
- ncs-package-alarm
- package-load-failure
- package-operation-failure
- ncs-service-manager-alarm
- service-activation-failure
- ncs-snmp-notification-receiver-alarm
- receiver-configuration-error
- time-violation-alarm
- transaction-lock-time-violation
-```
-
-## Alarm Type Descriptions
-
-System Call Trace
- -To catch certain types of problems, especially relating to system start and configuration, the operating system's system call trace can be invaluable. This tool is called `strace`/`ktrace`/`truss`. Please send the result to your support contact for a diagnosis. - -By running the instructions below. - -Linux: - -```bash -# strace -f -o mylog1.strace -s 1024 ncs ... -``` - -BSD: - -```bash -# ktrace -ad -f mylog1.ktrace ncs ... -# kdump -f mylog1.ktrace > mylog1.kdump -``` - -Solaris: - -```bash -# truss -f -o mylog1.truss ncs ... -``` - -
-
-
-
-abort-error
- -abort-error
-
-* **Initial Perceived Severity**
- major
-* **Description**
- An error happened while aborting or reverting a transaction. Device's
-configuration is likely to be inconsistent with the NCS CDB.
-* **Recommended Action**
- Inspect the configuration difference with compare-config,
- resolve conflicts with sync-from or sync-to if any.
-* **Clear Condition(s)**
- If NCS achieves sync with the device, or receives a transaction
- id for a netconf session towards the device, the alarm is cleared.
-* **Alarm Message(s)**
- * `Device {dev} is locked`
- * `Device {dev} is southbound locked`
- * `abort error`
-
-
-
-
-
-alarm-type
- -alarm-type
-
-* **Description**
- Base identity for alarm types. A unique identification of the
-fault, not including the managed object. Alarm types are used
-to identify if alarms indicate the same problem or not, for
-lookup into external alarm documentation, etc. Different
-managed object types and instances can share alarm types. If
-the same managed object reports the same alarm type, it is to
-be considered to be the same alarm. The alarm type is a
-simplification of the different X.733 and 3GPP alarm IRP alarm
-correlation mechanisms and it allows for hierarchical
-extensions.
-A 'specific-problem' can be used in addition to the alarm type
-in order to have different alarm types based on information not
-known at design-time, such as values in textual SNMP
-Notification varbinds.
-
-
-
-
-
-auto-configure-failed
- -auto-configure-failed
-
-* **Initial Perceived Severity**
- warning
-* **Description**
- Device auto-configure exhausted its retry attempts trying
-to connect and sync the device.
-* **Recommended Action**
- Make sure that NCS can connect to the device and then sync
- the configuration.
-* **Clear Condition(s)**
- If NCS achieves sync with the device, the alarm is cleared.
-* **Alarm Message(s)**
- * `Auto-configure has exhausted its retry attempts`
-
-
-
-
-
-cdb-offload-threshold-too-low
- -cdb-offload-threshold-too-low
-
-* **Initial Perceived Severity**
- warning
-* **Description**
- The CDB offload threshold configuration is set too low, causing
-the CDB memory footprint to reach the threshold even when there
-is no offloadable data present in the memory.
-* **Recommended Action**
- If system memory is sufficient, increase the threshold value, otherwise
- increase the system memory capacity.
-* **Clear Condition(s)**
- This alarm is cleared when CDB offload can lower the CDB memory
- footprint below the configured threshold value.
-* **Alarm Message(s)**
- * `CDB offload threshold is too low`
-
-
-
-
-
-certificate-expiration
- -certificate-expiration
-
-* **Description**
- The certificate is nearing its expiry or has already expired.
-The severity depends on the time left to expiry, it ranges from
-warning to critical.
-* **Recommended Action**
- Replace certificate.
-* **Clear Condition(s)**
- This alarm is cleared when the certificate is no longer loaded.
-* **Alarm Message(s)**
- * `Certificate expires in less than {days} day(s)`
- * `Certificate has expired`
-
-
-
-
-
-cluster-subscriber-failure
- -cluster-subscriber-failure
-
-* **Initial Perceived Severity**
- critical
-* **Description**
- Failure to establish a notification subscription towards
-a remote node.
-* **Recommended Action**
- Verify IP connectivity between cluster nodes.
-* **Clear Condition(s)**
- This alarm is cleared if NCS succeeds to establish a
- subscription towards the remote node, or when the subscription
- is explicitly stopped.
-* **Alarm Message(s)**
- * `Failed to establish netconf notification
- subscription to node ~s, stream ~s`
- * `Commit queue items with remote nodes will not receive required
- event notifications.`
-
-
-
-
-
-commit-through-queue-blocked
- -commit-through-queue-blocked
-
-* **Initial Perceived Severity**
- warning
-* **Description**
- A commit was queued behind a queue item waiting to be able to
-connect to one of its devices. This is potentially dangerous
-since one unreachable device can potentially fill up the commit
-queue indefinitely.
-* **Clear Condition(s)**
- An alarm raised due to a transient error will be cleared
- when NCS is able to reconnect to the device.
-* **Alarm Message(s)**
- * `Commit queue item ~p is blocked because item ~p cannot connect to ~s`
-
-
-
-
-
-commit-through-queue-failed
- -commit-through-queue-failed
-
-* **Initial Perceived Severity**
- critical
-* **Description**
- A queued commit failed.
-* **Recommended Action**
- Resolve with rollback if possible.
-* **Clear Condition(s)**
- This alarm is not cleared.
-* **Alarm Message(s)**
- * `Failed to authenticate towards device {device}: {reason}`
- * `Device {dev} is locked`
- * `{Reason}`
- * `Device {dev} is southbound locked`
- * `Commit queue item {CqId} rollback invoked`
- * `Commit queue item {CqId} has failed: Operation failed because:
- inconsistent database`
- * `Remote commit queue item ~p cannot be unlocked:
- cluster node not configured correctly`
-
-
-
-
-
-commit-through-queue-failed-transiently
- -commit-through-queue-failed-transiently
-
-* **Initial Perceived Severity**
- critical
-* **Description**
- A queued commit failed as it exhausted its retry attempts
-on transient errors.
-* **Recommended Action**
- Resolve with rollback if possible.
-* **Clear Condition(s)**
- This alarm is not cleared.
-* **Alarm Message(s)**
- * `Failed to connect to device {dev}: {reason}`
- * `Connection to {dev} timed out`
- * `Failed to authenticate towards device {device}: {reason}`
- * `The configuration database is locked for device {dev}: {reason}`
- * `the configuration database is locked by session {id} {identification}`
- * `the configuration database is locked by session {id} {identification}`
- * `{Dev}: Device is locked in a {Op} operation by session {session-id}`
- * `resource denied`
- * `Commit queue item {CqId} rollback invoked`
- * `Commit queue item {CqId} has failed: Operation failed because:
- inconsistent database`
- * `Remote commit queue item ~p cannot be unlocked:
- cluster node not configured correctly`
-
-
-
-
-
-commit-through-queue-rollback-failed
- -commit-through-queue-rollback-failed
-
-* **Initial Perceived Severity**
- critical
-* **Description**
- Rollback of a commit-queue item failed.
-* **Recommended Action**
- Investigate the status of the device and resolve the
- situation by issuing the appropriate action, i.e., service
- redeploy or a sync operation.
-* **Clear Condition(s)**
- This alarm is not cleared.
-* **Alarm Message(s)**
- * `{Reason}`
-
-
-
-
-
-configuration-error
- -configuration-error
-
-* **Initial Perceived Severity**
- critical
-* **Description**
- Invalid configuration of NCS managed device, NCS cannot recognize
-parameters needed to connect to device.
-* **Recommended Action**
- Verify that the configuration parameters defined in
- tailf-ncs-devices.yang submodule are consistent for this device.
-* **Clear Condition(s)**
- The alarm is cleared when NCS reads the configuration
- parameters for the device, and is raised again if the
- parameters are invalid.
-* **Alarm Message(s)**
- * `Failed to resolve IP address for {dev}`
- * `the configuration database is locked by session {id} {identification}`
- * `{Reason}`
- * `Resource {resource} doesn't exist`
-
-
-
-
-
-connection-failure
- -connection-failure
-
-* **Initial Perceived Severity**
- major
-* **Description**
- NCS failed to connect to a managed device before the timeout expired.
-* **Recommended Action**
- Verify address, port, authentication, check that the device is up
- and running. If the error occurs intermittently, increase
- connect-timeout.
-* **Clear Condition(s)**
- If NCS successfully reconnects to the device, the alarm is cleared.
-* **Alarm Message(s)**
- * `The connection to {dev} was closed`
- * `Failed to connect to device {dev}: {reason}`
-
-
-
-
-
-final-commit-error
- -final-commit-error
-
-* **Initial Perceived Severity**
- critical
-* **Description**
- A managed device validated a configuration change, but failed to
-commit. When this happens, NCS and the device are out of sync.
-* **Recommended Action**
- Reconcile by comparing and sync-from or sync-to.
-* **Clear Condition(s)**
- If NCS achieves sync with the device, the alarm is cleared.
-* **Alarm Message(s)**
- * `The connection to {dev} was closed`
- * `External error in the NED implementation for device {dev}: {reason}`
- * `Internal error in the NED NCS framework affecting device {dev}: {reason}`
-
-
-
-
-
-ha-alarm
- -ha-alarm
-
-* **Description**
- Base type for all alarms related to high availablity.
-This is never reported, sub-identities for the specific
-high availability alarms are used in the alarms.
-
-
-
-
-
-ha-node-down-alarm
- -ha-node-down-alarm
-
-* **Description**
- Base type for all alarms related to nodes going down in
-high availablity. This is never reported, sub-identities
-for the specific node down alarms are used in the alarms.
-
-
-
-
-
-ha-primary-down
- -ha-primary-down
-
-* **Initial Perceived Severity**
- critical
-* **Description**
- The node lost the connection to the primary node.
-* **Recommended Action**
- Make sure the HA cluster is operational, investigate why
- the primary went down and bring it up again.
-* **Clear Condition(s)**
- This alarm is never automatically cleared and has to be cleared
- manually when the HA cluster has been restored.
-* **Alarm Message(s)**
- * `Lost connection to primary due to: Primary closed connection`
- * `Lost connection to primary due to: Tick timeout`
- * `Lost connection to primary due to: code {Code}`
-
-
-
-
-
-ha-secondary-down
- -ha-secondary-down
-
-* **Initial Perceived Severity**
- critical
-* **Description**
- The node lost the connection to a secondary node.
-* **Recommended Action**
- Investigate why the secondary node went down, fix the
- connectivity issue and reconnect the secondary to the
- HA cluster.
-* **Clear Condition(s)**
- This alarm is cleared when the secondary node is reconnected
- to the HA cluster.
-* **Alarm Message(s)**
- * `Lost connection to secondary`
-
-
-
-
-
-missing-transaction-id
- -missing-transaction-id
-
-* **Initial Perceived Severity**
- warning
-* **Description**
- A device announced in its NETCONF hello message that
-it supports the transaction-id as defined in
-http://tail-f.com/yang/netconf-monitoring. However when
-NCS tries to read the transaction-id no data is returned.
-The NCS check-sync feature will not work. This is usually
-a case of misconfigured NACM rules on the managed device.
-* **Recommended Action**
- Verify NACM rules on the concerned device.
-* **Clear Condition(s)**
- If NCS successfully reads a transaction id for which
- it had previously failed to do so, the alarm is cleared.
-* **Alarm Message(s)**
- * `{Reason}`
-
-
-
-
-
-ncs-cluster-alarm
- -ncs-cluster-alarm
-
-* **Description**
- Base type for all alarms related to cluster.
-This is never reported, sub-identities for the specific
-cluster alarms are used in the alarms.
-
-
-
-
-
-ncs-dev-manager-alarm
- -ncs-dev-manager-alarm
-
-* **Description**
- Base type for all alarms related to the device manager
-This is never reported, sub-identities for the specific
-device alarms are used in the alarms.
-
-
-
-
-
-ncs-package-alarm
- -ncs-package-alarm
-
-* **Description**
- Base type for all alarms related to packages.
-This is never reported, sub-identities for the specific
-package alarms are used in the alarms.
-
-
-
-
-
-ncs-service-manager-alarm
- -ncs-service-manager-alarm
-
-* **Description**
- Base type for all alarms related to the service manager
-This is never reported, sub-identities for the specific
-service alarms are used in the alarms.
-
-
-
-
-
-ncs-snmp-notification-receiver-alarm
- -ncs-snmp-notification-receiver-alarm
-
-* **Description**
- Base type for SNMP notification receiver Alarms. This is never
-reported, sub-identities for specific SNMP notification receiver
-alarms are used in the alarms.
-
-
-
-
-
-ned-live-tree-connection-failure
- -ned-live-tree-connection-failure
-
-* **Initial Perceived Severity**
- major
-* **Description**
- NCS failed to connect to a managed device using one of the optional
-live-status-protocol NEDs.
-* **Recommended Action**
- Verify the configuration of the optional NEDs.
- If the error occurs intermittently, increase connect-timeout.
-* **Clear Condition(s)**
- If NCS successfully reconnects to the managed device,
- the alarm is cleared.
-* **Alarm Message(s)**
- * `The connection to {dev} was closed`
- * `Failed to connect to device {dev}: {reason}`
-
-
-
-
-
-out-of-sync
- -out-of-sync
-
-* **Initial Perceived Severity**
- major
-* **Description**
- A managed device is out of sync with NCS. Usually it means that the
-device has been configured out of band from NCS point of view.
-* **Recommended Action**
- Inspect the difference with compare-config, reconcile by
- invoking sync-from or sync-to.
-* **Clear Condition(s)**
- If NCS achieves sync with the device, the alarm is cleared.
-* **Alarm Message(s)**
- * `Device {dev} is out of sync`
- * `Out of sync due to no-networking or failed commit-queue commits.`
- * `got: ~s expected: ~s.`
-
-
-
-
-
-package-load-failure
- -package-load-failure
-
-* **Initial Perceived Severity**
- critical
-* **Description**
- NCS failed to load a package.
-* **Recommended Action**
- Check the package for the reason.
-* **Clear Condition(s)**
- If NCS successfully loads a package for which an alarm
- was previously raised, it will be cleared.
-* **Alarm Message(s)**
- * `failed to open file {file}: {str}`
- * `Specific to the concerned package.`
-
-
-
-
-
-package-operation-failure
- -package-operation-failure
-
-* **Initial Perceived Severity**
- critical
-* **Description**
- A package has some problem with its operation.
-* **Recommended Action**
- Check the package for the reason.
-* **Clear Condition(s)**
- This alarm is not cleared.
-
-
-
-
-
-receiver-configuration-error
- -receiver-configuration-error
-
-* **Initial Perceived Severity**
- major
-* **Description**
- The snmp-notification-receiver could not setup its configuration,
-either at startup or when reconfigured. SNMP notifications will now
-be missed.
-* **Recommended Action**
- Check the error-message and change the configuration.
-* **Clear Condition(s)**
- This alarm will be cleared when the NCS is configured
- to successfully receive SNMP notifications
-* **Alarm Message(s)**
- * `Configuration has errors.`
-
-
-
-
-
-revision-error
- -revision-error
-
-* **Initial Perceived Severity**
- major
-* **Description**
- A managed device arrived with a known module, but too new revision.
-* **Recommended Action**
- Upgrade the Device NED using the new YANG revision in order
- to use the new features in the device.
-* **Clear Condition(s)**
- If all device yang modules are supported by NCS,
- the alarm is cleared.
-* **Alarm Message(s)**
- * `The device has YANG module revisions not supported by
- NCS. Use the /devices/device/check-yang-modules
- action to check which modules that are not compatible.`
-
-
-
-
-
-service-activation-failure
- -service-activation-failure
-
-* **Initial Perceived Severity**
- critical
-* **Description**
- A service failed during re-deploy.
-* **Recommended Action**
- Corrective action and another re-deploy is needed.
-* **Clear Condition(s)**
- If the service is successfully redeployed, the alarm is cleared.
-* **Alarm Message(s)**
- * `Multiple device errors:
-{str}`
-
-
-
-
-
-time-violation-alarm
- -time-violation-alarm
-
-* **Description**
- Base type for all alarms related to time violations.
-This is never reported, sub-identities for the specific
-time violation alarms are used in the alarms.
-
-
-
-
-
diff --git a/administration/management/system-management/cisco-smart-licensing.md b/administration/management/system-management/cisco-smart-licensing.md
deleted file mode 100644
index 780327df..00000000
--- a/administration/management/system-management/cisco-smart-licensing.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-description: Manage purchase and licensing of Cisco software.
----
-
-# Cisco Smart Licensing
-
-[Cisco Smart Licensing](https://www.cisco.com/web/ordering/smart-software-licensing/index.html) is a cloud-based approach to licensing, and it simplifies the purchase, deployment, and management of Cisco software assets. Entitlements are purchased through a Cisco account via Cisco Commerce Workspace (CCW) and are immediately deposited into a Smart Account for usage. This eliminates the need to install license files on every device. Products that are smart-enabled communicate directly to Cisco to report consumption.
-
-Cisco Smart Software Manager (CSSM) enables the management of software licenses and Smart Account from a single portal. The interface allows you to activate your product, manage entitlements, and renew and upgrade software.
-
-A functioning Smart Account is required to complete the registration process. For detailed information about CSSM, see [Cisco Smart Software Manager](https://www.cisco.com/c/en/us/buy/smart-accounts/software-manager.html).
-
-## Smart Accounts and Virtual Accounts
-
-A virtual account exists as a sub-account within the Smart Account. Virtual accounts are a customer-defined structure based on organizational layout, business function, geography, or any defined hierarchy. They are created and maintained by the Smart Account administrator(s).
-
-Visit [Cisco Cisco Software Central](https://software.cisco.com/) to learn about how to create and manage Smart Accounts.
-
-### Request a Smart Account
-
-The creation of a new Smart Account is a one-time event, and subsequent management of users is a capability provided through the tool. To request a Smart Account, visit [Cisco Cisco Software Central](https://software.cisco.com/) and take the following steps:
-
-1. After logging in, select **Request a Smart Account** in the Administration section.
-
- transaction-lock-time-violation
- -transaction-lock-time-violation
-
-* **Initial Perceived Severity**
- warning
-* **Description**
- The transaction lock time exceeded its threshold and might be stuck
-in the critical section. This threshold is configured in
-/ncs-config/transaction-lock-time-violation-alarm/timeout.
-* **Recommended Action**
- Investigate if the transaction is stuck and possibly
- interrupt it by closing the user session which it is
- attached to.
-* **Clear Condition(s)**
- This alarm is cleared when the transaction has finished.
-* **Alarm Message(s)**
- * `Transaction lock time exceeded threshold.`
-
-
-
-
-
-
-AAA_LOAD_FAIL
- -AAA_LOAD_FAIL
-
-* **Severity**
- `CRIT`
-* **Description**
- Failed to load the AAA data, it could be that an external db is misbehaving or AAA is mounted/populated badly
-* **Format String**
- `"Failed to load AAA: ~s"`
-
-
-
-
-
-
-ABORT_CAND_COMMIT
- -ABORT_CAND_COMMIT
-
-* **Severity**
- `INFO`
-* **Description**
- Aborting candidate commit, request from user, reverting configuration.
-* **Format String**
- `"Aborting candidate commit, request from user, reverting configuration."`
-
-
-
-
-
-
-ABORT_CAND_COMMIT_REBOOT
- -ABORT_CAND_COMMIT_REBOOT
-
-* **Severity**
- `INFO`
-* **Description**
- ConfD restarted while having a ongoing candidate commit timer, reverting configuration.
-* **Format String**
- `"ConfD restarted while having a ongoing candidate commit timer, reverting configuration."`
-
-
-
-
-
-
-ABORT_CAND_COMMIT_TERM
- -ABORT_CAND_COMMIT_TERM
-
-* **Severity**
- `INFO`
-* **Description**
- Candidate commit session terminated, reverting configuration.
-* **Format String**
- `"Candidate commit session terminated, reverting configuration."`
-
-
-
-
-
-
-ABORT_CAND_COMMIT_TIMER
- -ABORT_CAND_COMMIT_TIMER
-
-* **Severity**
- `INFO`
-* **Description**
- Candidate commit timer expired, reverting configuration.
-* **Format String**
- `"Candidate commit timer expired, reverting configuration."`
-
-
-
-
-
-
-ACCEPT_FATAL
- -ACCEPT_FATAL
-
-* **Severity**
- `CRIT`
-* **Description**
- ConfD encountered an OS-specific error indicating that networking support is unavailable.
-* **Format String**
- `"Fatal error for accept() - ~s"`
-
-
-
-
-
-
-ACCEPT_FDLIMIT
- -ACCEPT_FDLIMIT
-
-* **Severity**
- `CRIT`
-* **Description**
- ConfD failed to accept a connection due to reaching the process or system-wide file descriptor limit.
-* **Format String**
- `"Out of file descriptors for accept() - ~s limit reached"`
-
-
-
-
-
-
-AUTH_LOGIN_FAIL
- -AUTH_LOGIN_FAIL
-
-* **Severity**
- `INFO`
-* **Description**
- A user failed to log in to ConfD.
-* **Format String**
- `"login failed via ~s from ~s with ~s: ~s"`
-
-
-
-
-
-
-AUTH_LOGIN_SUCCESS
- -AUTH_LOGIN_SUCCESS
-
-* **Severity**
- `INFO`
-* **Description**
- A user logged into ConfD.
-* **Format String**
- `"logged in to ~s via ~s from ~s with ~s using ~s authentication"`
-
-
-
-
-
-
-AUTH_LOGOUT
- -AUTH_LOGOUT
-
-* **Severity**
- `INFO`
-* **Description**
- A user was logged out from ConfD.
-* **Format String**
- `"logged out <~s> user"`
-
-
-
-
-
-
-BADCONFIG
- -BADCONFIG
-
-* **Severity**
- `CRIT`
-* **Description**
- confd.conf contained bad data.
-* **Format String**
- `"Bad configuration: ~s:~s: ~s"`
-
-
-
-
-
-
-BAD_DEPENDENCY
- -BAD_DEPENDENCY
-
-* **Severity**
- `ERR`
-* **Description**
- A dependency was not found
-* **Format String**
- `"The dependency node '~s' for node '~s' in module '~s' does not exist"`
-
-
-
- to confdc when linking the .xso files to force another value for the namespace hash.
-* **Format String**
- `"~s"`
-
-
-
-
-BAD_NS_HASH
- -BAD_NS_HASH
-
-* **Severity**
- `CRIT`
-* **Description**
- Two namespaces have the same hash value. The namespace hashvalue MUST be unique. You can pass the flag --nshash
-
-
-
-
-BIND_ERR
- -BIND_ERR
-
-* **Severity**
- `CRIT`
-* **Description**
- ConfD failed to bind to one of the internally used listen sockets.
-* **Format String**
- `"~s"`
-
-
-
-
-
-
-BRIDGE_DIED
- -BRIDGE_DIED
-
-* **Severity**
- `ERR`
-* **Description**
- ConfD is configured to start the confd_aaa_bridge and the C program died.
-* **Format String**
- `"confd_aaa_bridge died - ~s"`
-
-
-
-
-
-
-CANDIDATE_BAD_FILE_FORMAT
- -CANDIDATE_BAD_FILE_FORMAT
-
-* **Severity**
- `WARNING`
-* **Description**
- The candidate database file has a bad format. The candidate database is reset to the empty database.
-* **Format String**
- `"Bad format found in candidate db file ~s; resetting candidate"`
-
-
-
-
-
-
-CANDIDATE_CORRUPT_FILE
- -CANDIDATE_CORRUPT_FILE
-
-* **Severity**
- `WARNING`
-* **Description**
- The candidate database file is corrupt and cannot be read. The candidate database is reset to the empty database.
-* **Format String**
- `"Corrupt candidate db file ~s; resetting candidate"`
-
-
-
-
-
-
-CAND_COMMIT_ROLLBACK_DONE
- -CAND_COMMIT_ROLLBACK_DONE
-
-* **Severity**
- `INFO`
-* **Description**
- Candidate commit rollback done
-* **Format String**
- `"Candidate commit rollback done"`
-
-
-
-
-
-
-CAND_COMMIT_ROLLBACK_FAILURE
- -CAND_COMMIT_ROLLBACK_FAILURE
-
-* **Severity**
- `ERR`
-* **Description**
- Failed to rollback candidate commit
-* **Format String**
- `"Failed to rollback candidate commit due to: ~s"`
-
-
-
-
-
-
-CDB_BACKUP
- -CDB_BACKUP
-
-* **Severity**
- `INFO`
-* **Description**
- CDB data backed up after migration to a new storage backend.
-* **Format String**
- `"CDB: ~s backed up to ~s"`
-
-
-
-
-
-
-CDB_BOOT_ERR
- -CDB_BOOT_ERR
-
-* **Severity**
- `CRIT`
-* **Description**
- CDB failed to start. Some grave error in the cdb data files prevented CDB from starting - a recovery from backup is necessary.
-* **Format String**
- `"CDB boot error: ~s"`
-
-
-
-
-
-
-CDB_CLIENT_TIMEOUT
- -CDB_CLIENT_TIMEOUT
-
-* **Severity**
- `ERR`
-* **Description**
- A CDB client failed to answer within the timeout period. The client will be disconnected.
-* **Format String**
- `"CDB client (~s) timed out, waiting for ~s"`
-
-
-
-
-
-
-CDB_CONFIG_LOST
- -CDB_CONFIG_LOST
-
-* **Severity**
- `INFO`
-* **Description**
- CDB found it's data files but no schema file. CDB recovers by starting from an empty database.
-* **Format String**
- `"CDB: lost config, deleting DB"`
-
-
-
-
-
-
-CDB_DB_LOST
- -CDB_DB_LOST
-
-* **Severity**
- `INFO`
-* **Description**
- CDB found it's data schema file but not it's data file. CDB recovers by starting from an empty database.
-* **Format String**
- `"CDB: lost DB, deleting old config"`
-
-
-
-
-
-
-CDB_FATAL_ERROR
- -CDB_FATAL_ERROR
-
-* **Severity**
- `CRIT`
-* **Description**
- CDB encounterad an unrecoverable error
-* **Format String**
- `"fatal error in CDB: ~s"`
-
-
-
-
-
-
-CDB_INIT_LOAD
- -CDB_INIT_LOAD
-
-* **Severity**
- `INFO`
-* **Description**
- CDB is processing an initialization file.
-* **Format String**
- `"CDB load: processing file: ~s"`
-
-
-
-
-
-
-CDB_MIGRATE
- -CDB_MIGRATE
-
-* **Severity**
- `INFO`
-* **Description**
- CDB data migration to a new storage backend.
-* **Format String**
- `"CDB: migrate ~s to ~s"`
-
-
-
-
-
-
-CDB_OFFLOAD
- -CDB_OFFLOAD
-
-* **Severity**
- `DEBUG`
-* **Description**
- CDB data offload started.
-* **Format String**
- `"CDB: offload ~s from memory"`
-
-
-
-
-
-
-CDB_OP_INIT
- -CDB_OP_INIT
-
-* **Severity**
- `ERR`
-* **Description**
- The operational DB was deleted and re-initialized (because of upgrade or corrupt file)
-* **Format String**
- `"CDB: Operational DB re-initialized"`
-
-
-
-
-
-
-CDB_STALE_BACKUP
- -CDB_STALE_BACKUP
-
-* **Severity**
- `INFO`
-* **Description**
- CDB backup data left on disk after migration that can be removed to free up disk space.
-* **Format String**
- `"CDB: ~s backup file(s) occupying ~sMiB, remove to free up disk space: ~s"`
-
-
-
-
-
-
-CDB_UPGRADE_FAILED
- -CDB_UPGRADE_FAILED
-
-* **Severity**
- `ERR`
-* **Description**
- Automatic CDB upgrade failed. This means that the data model has been changed in a non-supported way.
-* **Format String**
- `"CDB: Upgrade failed: ~s"`
-
-
-
-
-
-
-CGI_REQUEST
- -CGI_REQUEST
-
-* **Severity**
- `INFO`
-* **Description**
- CGI script requested.
-* **Format String**
- `"CGI: '~s' script with method ~s"`
-
-
-
-
-
-
-CHANGE_USER
- -CHANGE_USER
-
-* **Severity**
- `INFO`
-* **Description**
- A NETCONF request to change user for authorization was succesfully done.
-* **Format String**
- `"changed user to ~s, groups ~s"`
-
-
-
-
-
-
-CLI_CMD
- -CLI_CMD
-
-* **Severity**
- `INFO`
-* **Description**
- User executed a CLI command.
-* **Format String**
- `"CLI '~s'"`
-
-
-
-
-
-
-CLI_CMD_ABORTED
- -CLI_CMD_ABORTED
-
-* **Severity**
- `INFO`
-* **Description**
- CLI command aborted.
-* **Format String**
- `"CLI aborted"`
-
-
-
-
-
-
-CLI_CMD_DONE
- -CLI_CMD_DONE
-
-* **Severity**
- `INFO`
-* **Description**
- CLI command finished successfully.
-* **Format String**
- `"CLI done"`
-
-
-
-
-
-
-CLI_DENIED
- -CLI_DENIED
-
-* **Severity**
- `INFO`
-* **Description**
- User was denied to execute a CLI command due to permissions.
-* **Format String**
- `"CLI denied '~s'"`
-
-
-
-
-
-
-COMMIT_INFO
- -COMMIT_INFO
-
-* **Severity**
- `INFO`
-* **Description**
- Information about configuration changes committed to the running data store.
-* **Format String**
- `"commit ~s"`
-
-
-
-
-
-
-COMMIT_QUEUE_CORRUPT
- -COMMIT_QUEUE_CORRUPT
-
-* **Severity**
- `ERR`
-* **Description**
- Failed to load commit queue. ConfD recovers by starting from an empty commit queue.
-* **Format String**
- `"Resetting commit queue due do inconsistent or corrupt data."`
-
-
-
-
-
-
-CONFIG_CHANGE
- -CONFIG_CHANGE
-
-* **Severity**
- `INFO`
-* **Description**
- A change to ConfD configuration has taken place, e.g., by a reload of the configuration file
-* **Format String**
- `"ConfD configuration change: ~s"`
-
-
-
-
-
-
-CONFIG_DEPRECATED
- -CONFIG_DEPRECATED
-
-* **Severity**
- `WARNING`
-* **Description**
- confd.conf contains a deprecated value
-* **Format String**
- `"Config value is deprecated: ~s"`
-
-
-
-
-
-
-CONFIG_OBSOLETE
- -CONFIG_OBSOLETE
-
-* **Severity**
- `WARNING`
-* **Description**
- confd.conf contains an obsolete value
-* **Format String**
- `"Config value is obsolete: ~s"`
-
-
-
-
-
-
-CONFIG_TRANSACTION_LIMIT
- -CONFIG_TRANSACTION_LIMIT
-
-* **Severity**
- `INFO`
-* **Description**
- Configuration transaction limit reached, rejected new transaction request.
-* **Format String**
- `"Configuration transaction limit of type '~s' reached, rejected new transaction request"`
-
-
-
-
-
-
-CONSULT_FILE
- -CONSULT_FILE
-
-* **Severity**
- `INFO`
-* **Description**
- ConfD is reading its configuration file.
-* **Format String**
- `"Consulting daemon configuration file ~s"`
-
-
-
-
-
-
-CRYPTO_KEYS_FAILED_LOADING
- -CRYPTO_KEYS_FAILED_LOADING
-
-* **Severity**
- `INFO`
-* **Description**
- Crypto keys failed to load because the old active generation is missing in the new configuration.
-* **Format String**
- `"Cannot reload crypto keys since the old active generation is missing in the new list of keys."`
-
-
-
-
-
-
-DAEMON_DIED
- -DAEMON_DIED
-
-* **Severity**
- `CRIT`
-* **Description**
- An external database daemon closed its control socket.
-* **Format String**
- `"Daemon ~s died"`
-
-
-
-
-
-
-DAEMON_TIMEOUT
- -DAEMON_TIMEOUT
-
-* **Severity**
- `CRIT`
-* **Description**
- An external database daemon did not respond to a query.
-* **Format String**
- `"Daemon ~s timed out"`
-
-
-
-
-
-
-DEVEL_AAA
- -DEVEL_AAA
-
-* **Severity**
- `INFO`
-* **Description**
- Developer aaa log message
-* **Format String**
- `"~s"`
-
-
-
-
-
-
-DEVEL_CAPI
- -DEVEL_CAPI
-
-* **Severity**
- `INFO`
-* **Description**
- Developer C api log message
-* **Format String**
- `"~s"`
-
-
-
-
-
-
-DEVEL_CDB
- -DEVEL_CDB
-
-* **Severity**
- `INFO`
-* **Description**
- Developer CDB log message
-* **Format String**
- `"~s"`
-
-
-
-
-
-
-DEVEL_CONFD
- -DEVEL_CONFD
-
-* **Severity**
- `INFO`
-* **Description**
- Developer ConfD log message
-* **Format String**
- `"~s"`
-
-
-
-
-
-
-DEVEL_ECONFD
- -DEVEL_ECONFD
-
-* **Severity**
- `INFO`
-* **Description**
- Developer econfd api log message
-* **Format String**
- `"~s"`
-
-
-
-
-
-
-DEVEL_SLS
- -DEVEL_SLS
-
-* **Severity**
- `INFO`
-* **Description**
- Developer smartlicensing api log message
-* **Format String**
- `"~s"`
-
-
-
-
-
-
-DEVEL_SNMPA
- -DEVEL_SNMPA
-
-* **Severity**
- `INFO`
-* **Description**
- Developer snmp agent log message
-* **Format String**
- `"~s"`
-
-
-
-
-
-
-DEVEL_SNMPGW
- -DEVEL_SNMPGW
-
-* **Severity**
- `INFO`
-* **Description**
- Developer snmp GW log message
-* **Format String**
- `"~s"`
-
-
-
-
-
-
-DEVEL_WEBUI
- -DEVEL_WEBUI
-
-* **Severity**
- `INFO`
-* **Description**
- Developer webui log message
-* **Format String**
- `"~s"`
-
-
-
-
-
-
-DUPLICATE_MODULE_NAME
- -DUPLICATE_MODULE_NAME
-
-* **Severity**
- `CRIT`
-* **Description**
- Duplicate module name found.
-* **Format String**
- `"The module name '~s' is both defined in '~s' and '~s'."`
-
-
-
-
-
-
-DUPLICATE_NAMESPACE
- -DUPLICATE_NAMESPACE
-
-* **Severity**
- `CRIT`
-* **Description**
- Duplicate namespace found.
-* **Format String**
- `"The namespace ~s is defined in both module ~s and ~s."`
-
-
-
-
-
-
-DUPLICATE_PREFIX
- -DUPLICATE_PREFIX
-
-* **Severity**
- `CRIT`
-* **Description**
- Duplicate prefix found.
-* **Format String**
- `"The prefix ~s is defined in both ~s and ~s."`
-
-
-
-
-
-
-ERRLOG_SIZE_CHANGED
- -ERRLOG_SIZE_CHANGED
-
-* **Severity**
- `INFO`
-* **Description**
- Notify change of log size for error log
-* **Format String**
- `"Changing size of error log (~s) to ~s (was ~s)"`
-
-
-
-
-
-
-EVENT_SOCKET_TIMEOUT
- -EVENT_SOCKET_TIMEOUT
-
-* **Severity**
- `CRIT`
-* **Description**
- An event notification subscriber did not reply within the configured timeout period
-* **Format String**
- `"Event notification subscriber with bitmask ~s timed out, waiting for ~s"`
-
-
-
-
-
-
-EVENT_SOCKET_WRITE_BLOCK
- -EVENT_SOCKET_WRITE_BLOCK
-
-* **Severity**
- `CRIT`
-* **Description**
- Write on an event socket blocked for too long time
-* **Format String**
- `"~s"`
-
-
-
-
-
-
-EXEC_WHEN_CIRCULAR_DEPENDENCY
- -EXEC_WHEN_CIRCULAR_DEPENDENCY
-
-* **Severity**
- `WARNING`
-* **Description**
- An error occurred while evaluating a when-expression.
-* **Format String**
- `"When-expression evaluation error: circular dependency in ~s"`
-
-
-
-
-
-
-EXTAUTH_BAD_RET
- -EXTAUTH_BAD_RET
-
-* **Severity**
- `ERR`
-* **Description**
- Authentication is external and the external program returned badly formatted data.
-* **Format String**
- `"External auth program (user=~s) ret bad output: ~s"`
-
-
-
-
-
-
-EXT_AUTH_2FA
- -EXT_AUTH_2FA
-
-* **Severity**
- `INFO`
-* **Description**
- External challenge sent to a user.
-* **Format String**
- `"external challenge sent to ~s from ~s with ~s"`
-
-
-
-
-
-
-EXT_AUTH_2FA_FAIL
- -EXT_AUTH_2FA_FAIL
-
-* **Severity**
- `INFO`
-* **Description**
- External challenge authentication failed for a user.
-* **Format String**
- `"external challenge authentication failed via ~s from ~s with ~s: ~s"`
-
-
-
-
-
-
-EXT_AUTH_2FA_SUCCESS
- -EXT_AUTH_2FA_SUCCESS
-
-* **Severity**
- `INFO`
-* **Description**
- An external challenge authenticated user logged in.
-* **Format String**
- `"external challenge authentication succeeded via ~s from ~s with ~s, member of groups: ~s~s"`
-
-
-
-
-
-
-EXT_AUTH_FAIL
- -EXT_AUTH_FAIL
-
-* **Severity**
- `INFO`
-* **Description**
- External authentication failed for a user.
-* **Format String**
- `"external authentication failed via ~s from ~s with ~s: ~s"`
-
-
-
-
-
-
-EXT_AUTH_SUCCESS
- -EXT_AUTH_SUCCESS
-
-* **Severity**
- `INFO`
-* **Description**
- An externally authenticated user logged in.
-* **Format String**
- `"external authentication succeeded via ~s from ~s with ~s, member of groups: ~s~s"`
-
-
-
-
-
-
-EXT_AUTH_TOKEN_FAIL
- -EXT_AUTH_TOKEN_FAIL
-
-* **Severity**
- `INFO`
-* **Description**
- External token authentication failed for a user.
-* **Format String**
- `"external token authentication failed via ~s from ~s with ~s: ~s"`
-
-
-
-
-
-
-EXT_AUTH_TOKEN_SUCCESS
- -EXT_AUTH_TOKEN_SUCCESS
-
-* **Severity**
- `INFO`
-* **Description**
- An externally token authenticated user logged in.
-* **Format String**
- `"external token authentication succeeded via ~s from ~s with ~s, member of groups: ~s~s"`
-
-
-
-
-
-
-EXT_BIND_ERR
- -EXT_BIND_ERR
-
-* **Severity**
- `CRIT`
-* **Description**
- ConfD failed to bind to one of the externally visible listen sockets.
-* **Format String**
- `"~s"`
-
-
-
-
-
-
-FILE_ERROR
- -FILE_ERROR
-
-* **Severity**
- `CRIT`
-* **Description**
- File error
-* **Format String**
- `"~s: ~s"`
-
-
-
-
-
-
-FILE_LOAD
- -FILE_LOAD
-
-* **Severity**
- `DEBUG`
-* **Description**
- System loaded a file.
-* **Format String**
- `"Loaded file ~s"`
-
-
-
-
-
-
-FILE_LOADING
- -FILE_LOADING
-
-* **Severity**
- `DEBUG`
-* **Description**
- System starts to load a file.
-* **Format String**
- `"Loading file ~s"`
-
-
-
-
-
-
-FILE_LOAD_ERR
- -FILE_LOAD_ERR
-
-* **Severity**
- `CRIT`
-* **Description**
- System tried to load a file in its load path and failed.
-* **Format String**
- `"Failed to load file ~s: ~s"`
-
-
-
-
-
-
-FXS_MISMATCH
- -FXS_MISMATCH
-
-* **Severity**
- `ERR`
-* **Description**
- A secondary connected to a primary where the fxs files are different
-* **Format String**
- `"Fxs mismatch, secondary is not allowed"`
-
-
-
-
-
-
-GROUP_ASSIGN
- -GROUP_ASSIGN
-
-* **Severity**
- `INFO`
-* **Description**
- A user was assigned to a set of groups.
-* **Format String**
- `"assigned to groups: ~s"`
-
-
-
-
-
-
-GROUP_NO_ASSIGN
- -GROUP_NO_ASSIGN
-
-* **Severity**
- `INFO`
-* **Description**
- A user was logged in but wasn't assigned to any groups at all.
-* **Format String**
- `"Not assigned to any groups - all access is denied"`
-
-
-
-
-
-
-HA_BAD_VSN
- -HA_BAD_VSN
-
-* **Severity**
- `ERR`
-* **Description**
- A secondary connected to a primary with an incompatible HA protocol version
-* **Format String**
- `"Incompatible HA version (~s, expected ~s), secondary is not allowed"`
-
-
-
-
-
-
-HA_DUPLICATE_NODEID
- -HA_DUPLICATE_NODEID
-
-* **Severity**
- `ERR`
-* **Description**
- A secondary arrived with a node id which already exists
-* **Format String**
- `"Nodeid ~s already exists"`
-
-
-
-
-
-
-HA_FAILED_CONNECT
- -HA_FAILED_CONNECT
-
-* **Severity**
- `ERR`
-* **Description**
- An attempted library become secondary call failed because the secondary couldn't connect to the primary
-* **Format String**
- `"Failed to connect to primary: ~s"`
-
-
-
-
-
-
-HA_SECONDARY_KILLED
- -HA_SECONDARY_KILLED
-
-* **Severity**
- `ERR`
-* **Description**
- A secondary node didn't produce its ticks
-* **Format String**
- `"Secondary ~s killed due to no ticks"`
-
-
-
-
-
-
-INTERNAL_ERROR
- -INTERNAL_ERROR
-
-* **Severity**
- `CRIT`
-* **Description**
- A ConfD internal error - should be reported to support@tail-f.com.
-* **Format String**
- `"Internal error: ~s"`
-
-
-
-
-
-
-IPC_CAPA_DBG_DUMP_DENIED
- -IPC_CAPA_DBG_DUMP_DENIED
-
-* **Severity**
- `INFO`
-* **Description**
- Debug dump denied for user - capability not enabled.
-* **Format String**
- `"Debug dump denied for user '~s' - capability not enabled."`
-
-
-
-
-
-
-IPC_CAPA_DBG_DUMP_GRANTED
- -IPC_CAPA_DBG_DUMP_GRANTED
-
-* **Severity**
- `INFO`
-* **Description**
- Debug dump allowed for user.
-* **Format String**
- `"Debug dump allowed for user '~s'."`
-
-
-
-
-
-
-JIT_ENABLED
- -JIT_ENABLED
-
-* **Severity**
- `INFO`
-* **Description**
- Show if JIT is enabled.
-* **Format String**
- `"JIT ~s"`
-
-
-
-
-
-
-JSONRPC_LOG_MSG
- -JSONRPC_LOG_MSG
-
-* **Severity**
- `INFO`
-* **Description**
- JSON-RPC traffic log message
-* **Format String**
- `"JSON-RPC traffic log: ~s"`
-
-
-
-
-
-
-JSONRPC_REQUEST
- -JSONRPC_REQUEST
-
-* **Severity**
- `INFO`
-* **Description**
- JSON-RPC method requested.
-* **Format String**
- `"JSON-RPC: '~s' with JSON params ~s"`
-
-
-
-
-
-
-JSONRPC_REQUEST_ABSOLUTE_TIMEOUT
- -JSONRPC_REQUEST_ABSOLUTE_TIMEOUT
-
-* **Severity**
- `INFO`
-* **Description**
- JSON-RPC absolute timeout.
-* **Format String**
- `"Stopping session due to absolute timeout: ~s"`
-
-
-
-
-
-
-JSONRPC_REQUEST_IDLE_TIMEOUT
- -JSONRPC_REQUEST_IDLE_TIMEOUT
-
-* **Severity**
- `INFO`
-* **Description**
- JSON-RPC idle timeout.
-* **Format String**
- `"Stopping session due to idle timeout: ~s"`
-
-
-
-
-
-
-JSONRPC_WARN_MSG
- -JSONRPC_WARN_MSG
-
-* **Severity**
- `WARNING`
-* **Description**
- JSON-RPC warning message
-* **Format String**
- `"JSON-RPC warning: ~s"`
-
-
-
-
-
-
-KICKER_MISSING_SCHEMA
- -KICKER_MISSING_SCHEMA
-
-* **Severity**
- `INFO`
-* **Description**
- Failed to load kicker schema
-* **Format String**
- `"Failed to load kicker schema"`
-
-
-
-
-
-
-LIB_BAD_SIZES
- -LIB_BAD_SIZES
-
-* **Severity**
- `ERR`
-* **Description**
- An application connecting to ConfD used a library version that can't handle the depth and number of keys used by the data model.
-* **Format String**
- `"Got connect from library with insufficient keypath depth/keys support (~s/~s, needs ~s/~s)"`
-
-
-
-
-
-
-LIB_BAD_VSN
- -LIB_BAD_VSN
-
-* **Severity**
- `ERR`
-* **Description**
- An application connecting to ConfD used a library version that doesn't match the ConfD version (e.g. old version of the client library).
-* **Format String**
- `"Got library connect from wrong version (~s, expected ~s)"`
-
-
-
-
-
-
-LIB_NO_ACCESS
- -LIB_NO_ACCESS
-
-* **Severity**
- `ERR`
-* **Description**
- Access check failure occurred when an application connected to ConfD.
-* **Format String**
- `"Got library connect with failed access check: ~s"`
-
-
-
-
-
-
-LISTENER_INFO
- -LISTENER_INFO
-
-* **Severity**
- `INFO`
-* **Description**
- ConfD starts or stops to listen for incoming connections.
-* **Format String**
- `"~s to listen for ~s on ~s:~s"`
-
-
-
-
-
-
-LOCAL_AUTH_FAIL
- -LOCAL_AUTH_FAIL
-
-* **Severity**
- `INFO`
-* **Description**
- Authentication for a locally configured user failed.
-* **Format String**
- `"local authentication failed via ~s from ~s with ~s: ~s"`
-
-
-
-
-
-
-LOCAL_AUTH_FAIL_BADPASS
- -LOCAL_AUTH_FAIL_BADPASS
-
-* **Severity**
- `INFO`
-* **Description**
- Authentication for a locally configured user failed due to providing bad password.
-* **Format String**
- `"local authentication failed via ~s from ~s with ~s: ~s"`
-
-
-
-
-
-
-LOCAL_AUTH_FAIL_NOUSER
- -LOCAL_AUTH_FAIL_NOUSER
-
-* **Severity**
- `INFO`
-* **Description**
- Authentication for a locally configured user failed due to user not found.
-* **Format String**
- `"local authentication failed via ~s from ~s with ~s: ~s"`
-
-
-
-
-
-
-LOCAL_AUTH_SUCCESS
- -LOCAL_AUTH_SUCCESS
-
-* **Severity**
- `INFO`
-* **Description**
- A locally authenticated user logged in.
-* **Format String**
- `"local authentication succeeded via ~s from ~s with ~s, member of groups: ~s"`
-
-
-
-
-
-
-LOCAL_IPC_ACCESS_DENIED
- -LOCAL_IPC_ACCESS_DENIED
-
-* **Severity**
- `INFO`
-* **Description**
- Local IPC access denied for user.
-* **Format String**
- `"Local IPC access denied for user ~s connecting from ~s"`
-
-
-
-
-
-
-LOGGING_DEST_CHANGED
- -LOGGING_DEST_CHANGED
-
-* **Severity**
- `INFO`
-* **Description**
- The target logfile will change to another file
-* **Format String**
- `"Changing destination of ~s log to ~s"`
-
-
-
-
-
-
-LOGGING_SHUTDOWN
- -LOGGING_SHUTDOWN
-
-* **Severity**
- `INFO`
-* **Description**
- Logging subsystem terminating
-* **Format String**
- `"Daemon logging terminating, reason: ~s"`
-
-
-
-
-
-
-LOGGING_STARTED
- -LOGGING_STARTED
-
-* **Severity**
- `INFO`
-* **Description**
- Logging subsystem started
-* **Format String**
- `"Daemon logging started"`
-
-
-
-
-
-
-LOGGING_STARTED_TO
- -LOGGING_STARTED_TO
-
-* **Severity**
- `INFO`
-* **Description**
- Write logs for a subsystem to a specific file
-* **Format String**
- `"Writing ~s log to ~s"`
-
-
-
-
-
-
-LOGGING_STATUS_CHANGED
- -LOGGING_STATUS_CHANGED
-
-* **Severity**
- `INFO`
-* **Description**
- Notify a change of logging status (enabled/disabled) for a subsystem
-* **Format String**
- `"~s ~s log"`
-
-
-
-
-
-
-LOGIN_REJECTED
- -LOGIN_REJECTED
-
-* **Severity**
- `INFO`
-* **Description**
- Authentication for a user was rejected by application callback.
-* **Format String**
- `"~s"`
-
-
-
-
-
-
-MAAPI_LOGOUT
- -MAAPI_LOGOUT
-
-* **Severity**
- `INFO`
-* **Description**
- A maapi user was logged out.
-* **Format String**
- `"Logged out from maapi ctx=~s (~s)"`
-
-
-
-
-
-
-MAAPI_WRITE_TO_SOCKET_FAIL
- -MAAPI_WRITE_TO_SOCKET_FAIL
-
-* **Severity**
- `INFO`
-* **Description**
- maapi failed to write to a socket.
-* **Format String**
- `"maapi server failed to write to a socket. Op: ~s Ecode: ~s Error: ~s~s"`
-
-
-
-
-
-
-MISSING_AES256CFB128_SETTINGS
- -MISSING_AES256CFB128_SETTINGS
-
-* **Severity**
- `ERR`
-* **Description**
- AES256CFB128 keys were not found in confd.conf
-* **Format String**
- `"AES256CFB128 keys were not found in confd.conf"`
-
-
-
-
-
-
-MISSING_AESCFB128_SETTINGS
- -MISSING_AESCFB128_SETTINGS
-
-* **Severity**
- `ERR`
-* **Description**
- AESCFB128 keys were not found in confd.conf
-* **Format String**
- `"AESCFB128 keys were not found in confd.conf"`
-
-
-
-
-
-
-MISSING_DES3CBC_SETTINGS
- -MISSING_DES3CBC_SETTINGS
-
-* **Severity**
- `ERR`
-* **Description**
- DES3CBC keys were not found in confd.conf
-* **Format String**
- `"DES3CBC keys were not found in confd.conf"`
-
-
-
-
-
-
-MISSING_NS
- -MISSING_NS
-
-* **Severity**
- `CRIT`
-* **Description**
- While validating the consistency of the config - a required namespace was missing.
-* **Format String**
- `"The namespace ~s could not be found in the loadPath."`
-
-
-
-
-
-
-MISSING_NS2
- -MISSING_NS2
-
-* **Severity**
- `CRIT`
-* **Description**
- While validating the consistency of the config - a required namespace was missing.
-* **Format String**
- `"The namespace ~s (referenced by ~s) could not be found in the loadPath."`
-
-
-
-
-
-
-MMAP_SCHEMA_FAIL
- -MMAP_SCHEMA_FAIL
-
-* **Severity**
- `ERR`
-* **Description**
- Failed to setup the shared memory schema
-* **Format String**
- `"Failed to setup the shared memory schema"`
-
-
-
-
-
-
-NETCONF
- -NETCONF
-
-* **Severity**
- `INFO`
-* **Description**
- NETCONF traffic log message
-* **Format String**
- `"~s"`
-
-
-
-
-
-
-NETCONF_HDR_ERR
- -NETCONF_HDR_ERR
-
-* **Severity**
- `ERR`
-* **Description**
- The cleartext header indicating user and groups was badly formatted.
-* **Format String**
- `"Got bad NETCONF TCP header"`
-
-
-
-
-
-
-NIF_LOG
- -NIF_LOG
-
-* **Severity**
- `INFO`
-* **Description**
- Log message from NIF code.
-* **Format String**
- `"~s: ~s"`
-
-
-
-
-
-
-NOAAA_CLI_LOGIN
- -NOAAA_CLI_LOGIN
-
-* **Severity**
- `INFO`
-* **Description**
- A user used the --noaaa flag to confd_cli
-* **Format String**
- `"logged in from the CLI with aaa disabled"`
-
-
-
-
-
-
-NOTIFICATION_REPLAY_STORE_FAILURE
- -NOTIFICATION_REPLAY_STORE_FAILURE
-
-* **Severity**
- `CRIT`
-* **Description**
- A failure occurred in the builtin notification replay store
-* **Format String**
- `"~s"`
-
-
-
-
-
-
-NO_CALLPOINT
- -NO_CALLPOINT
-
-* **Severity**
- `CRIT`
-* **Description**
- ConfD tried to populate an XML tree but no code had registered under the relevant callpoint.
-* **Format String**
- `"no registration found for callpoint ~s of type=~s"`
-
-
-
-
-
-
-NO_SUCH_IDENTITY
- -NO_SUCH_IDENTITY
-
-* **Severity**
- `CRIT`
-* **Description**
- The fxs file with the base identity is not loaded
-* **Format String**
- `"The identity ~s in namespace ~s refers to a non-existing base identity ~s in namespace ~s"`
-
-
-
-
-
-
-NO_SUCH_NS
- -NO_SUCH_NS
-
-* **Severity**
- `CRIT`
-* **Description**
- A nonexistent namespace was referred to. Typically this means that a .fxs was missing from the loadPath.
-* **Format String**
- `"No such namespace ~s, used by ~s"`
-
-
-
-
-
-
-NO_SUCH_TYPE
- -NO_SUCH_TYPE
-
-* **Severity**
- `CRIT`
-* **Description**
- A nonexistent type was referred to from a ns. Typically this means that a bad version of an .fxs file was found in the loadPath.
-* **Format String**
- `"No such simpleType '~s' in ~s, used by ~s"`
-
-
-
-
-
-
-NS_LOAD_ERR
- -NS_LOAD_ERR
-
-* **Severity**
- `CRIT`
-* **Description**
- System tried to process a loaded namespace and failed.
-* **Format String**
- `"Failed to process namespace ~s: ~s"`
-
-
-
-
-
-
-NS_LOAD_ERR2
- -NS_LOAD_ERR2
-
-* **Severity**
- `CRIT`
-* **Description**
- System tried to process a loaded namespace and failed.
-* **Format String**
- `"Failed to process namespaces: ~s"`
-
-
-
-
-
-
-OPEN_LOGFILE
- -OPEN_LOGFILE
-
-* **Severity**
- `INFO`
-* **Description**
- Indicate target file for certain type of logging
-* **Format String**
- `"Logging subsystem, opening log file '~s' for ~s"`
-
-
-
-
-
-
-PAM_AUTH_FAIL
- -PAM_AUTH_FAIL
-
-* **Severity**
- `INFO`
-* **Description**
- A user failed to authenticate through PAM.
-* **Format String**
- `"PAM authentication failed via ~s from ~s with ~s: phase ~s, ~s"`
-
-
-
-
-
-
-PAM_AUTH_SUCCESS
- -PAM_AUTH_SUCCESS
-
-* **Severity**
- `INFO`
-* **Description**
- A PAM authenticated user logged in.
-* **Format String**
- `"pam authentication succeeded via ~s from ~s with ~s"`
-
-
-
-
-
-
-PHASE0_STARTED
- -PHASE0_STARTED
-
-* **Severity**
- `INFO`
-* **Description**
- ConfD has just started its start phase 0.
-* **Format String**
- `"ConfD phase0 started"`
-
-
-
-
-
-
-PHASE1_STARTED
- -PHASE1_STARTED
-
-* **Severity**
- `INFO`
-* **Description**
- ConfD has just started its start phase 1.
-* **Format String**
- `"ConfD phase1 started"`
-
-
-
-
-
-
-READ_STATE_FILE_FAILED
- -READ_STATE_FILE_FAILED
-
-* **Severity**
- `CRIT`
-* **Description**
- Reading of a state file failed
-* **Format String**
- `"Reading state file failed: ~s: ~s (~s)"`
-
-
-
-
-
-
-RELOAD
- -RELOAD
-
-* **Severity**
- `INFO`
-* **Description**
- Reload of daemon configuration has been initiated.
-* **Format String**
- `"Reloading daemon configuration."`
-
-
-
-
-
-
-REOPEN_LOGS
- -REOPEN_LOGS
-
-* **Severity**
- `INFO`
-* **Description**
- Logging subsystem, reopening log files
-* **Format String**
- `"Logging subsystem, reopening log files"`
-
-
-
-
-
-
-RESTCONF_REQUEST
- -RESTCONF_REQUEST
-
-* **Severity**
- `INFO`
-* **Description**
- RESTCONF request
-* **Format String**
- `"RESTCONF: request with ~s: ~s"`
-
-
-
-
-
-
-RESTCONF_RESPONSE
- -RESTCONF_RESPONSE
-
-* **Severity**
- `INFO`
-* **Description**
- RESTCONF response
-* **Format String**
- `"RESTCONF: response with ~s: ~s duration ~s us"`
-
-
-
-
-
-
-REST_AUTH_FAIL
- -REST_AUTH_FAIL
-
-* **Severity**
- `INFO`
-* **Description**
- Rest authentication for a user failed.
-* **Format String**
- `"rest authentication failed from ~s"`
-
-
-
-
-
-
-REST_AUTH_SUCCESS
- -REST_AUTH_SUCCESS
-
-* **Severity**
- `INFO`
-* **Description**
- A rest authenticated user logged in.
-* **Format String**
- `"rest authentication succeeded from ~s , member of groups: ~s"`
-
-
-
-
-
-
-REST_REQUEST
- -REST_REQUEST
-
-* **Severity**
- `INFO`
-* **Description**
- REST request
-* **Format String**
- `"REST: request with ~s: ~s"`
-
-
-
-
-
-
-REST_RESPONSE
- -REST_RESPONSE
-
-* **Severity**
- `INFO`
-* **Description**
- REST response
-* **Format String**
- `"REST: response with ~s: ~s duration ~s ms"`
-
-
-
-
-
-
-ROLLBACK_FAIL_CREATE
- -ROLLBACK_FAIL_CREATE
-
-* **Severity**
- `ERR`
-* **Description**
- Error while creating rollback file.
-* **Format String**
- `"Error while creating rollback file: ~s: ~s"`
-
-
-
-
-
-
-ROLLBACK_FAIL_DELETE
- -ROLLBACK_FAIL_DELETE
-
-* **Severity**
- `ERR`
-* **Description**
- Failed to delete rollback file.
-* **Format String**
- `"Failed to delete rollback file ~s: ~s"`
-
-
-
-
-
-
-ROLLBACK_FAIL_RENAME
- -ROLLBACK_FAIL_RENAME
-
-* **Severity**
- `ERR`
-* **Description**
- Failed to rename rollback file.
-* **Format String**
- `"Failed to rename rollback file ~s to ~s: ~s"`
-
-
-
-
-
-
-ROLLBACK_FAIL_REPAIR
- -ROLLBACK_FAIL_REPAIR
-
-* **Severity**
- `ERR`
-* **Description**
- Failed to repair rollback files.
-* **Format String**
- `"Failed to repair rollback files."`
-
-
-
-
-
-
-ROLLBACK_REMOVE
- -ROLLBACK_REMOVE
-
-* **Severity**
- `INFO`
-* **Description**
- Found half created rollback0 file - removing and creating new.
-* **Format String**
- `"Found half created rollback0 file - removing and creating new"`
-
-
-
-
-
-
-ROLLBACK_REPAIR
- -ROLLBACK_REPAIR
-
-* **Severity**
- `INFO`
-* **Description**
- Found half created rollback0 file - repairing.
-* **Format String**
- `"Found half created rollback0 file - repairing"`
-
-
-
-
-
-
-SESSION_CREATE
- -SESSION_CREATE
-
-* **Severity**
- `INFO`
-* **Description**
- A new user session was created
-* **Format String**
- `"created new session via ~s from ~s with ~s"`
-
-
-
-
-
-
-SESSION_LIMIT
- -SESSION_LIMIT
-
-* **Severity**
- `INFO`
-* **Description**
- Session limit reached, rejected new session request.
-* **Format String**
- `"Session limit of type '~s' reached, rejected new session request"`
-
-
-
-
-
-
-SESSION_MAX_EXCEEDED
- -SESSION_MAX_EXCEEDED
-
-* **Severity**
- `INFO`
-* **Description**
- A user failed to create a new user sessions due to exceeding sessions limits
-* **Format String**
- `"could not create new session via ~s from ~s with ~s due to session limits"`
-
-
-
-
-
-
-SESSION_TERMINATION
- -SESSION_TERMINATION
-
-* **Severity**
- `INFO`
-* **Description**
- A user session was terminated due to specified reason
-* **Format String**
- `"terminated session (reason: ~s)"`
-
-
-
-
-
-
-SKIP_FILE_LOADING
- -SKIP_FILE_LOADING
-
-* **Severity**
- `DEBUG`
-* **Description**
- System skips a file.
-* **Format String**
- `"Skipping file ~s: ~s"`
-
-
-
-
-
-
-SNMP_AUTHENTICATION_FAILED
- -SNMP_AUTHENTICATION_FAILED
-
-* **Severity**
- `INFO`
-* **Description**
- An SNMP authentication failed.
-* **Format String**
- `"SNMP authentication failed: ~s"`
-
-
-
-
-
-
-SNMP_CANT_LOAD_MIB
- -SNMP_CANT_LOAD_MIB
-
-* **Severity**
- `CRIT`
-* **Description**
- The SNMP Agent failed to load a MIB file
-* **Format String**
- `"Can't load MIB file: ~s"`
-
-
-
-
-
-
-SNMP_MIB_LOADING
- -SNMP_MIB_LOADING
-
-* **Severity**
- `DEBUG`
-* **Description**
- SNMP Agent loading a MIB file
-* **Format String**
- `"Loading MIB: ~s"`
-
-
-
-
-
-
-SNMP_NOT_A_TRAP
- -SNMP_NOT_A_TRAP
-
-* **Severity**
- `INFO`
-* **Description**
- An UDP package was received on the trap receiving port, but it's not an SNMP trap.
-* **Format String**
- `"SNMP gateway: Non-trap received from ~s"`
-
-
-
-
-
-
-SNMP_READ_STATE_FILE_FAILED
- -SNMP_READ_STATE_FILE_FAILED
-
-* **Severity**
- `CRIT`
-* **Description**
- Read SNMP agent state file failed
-* **Format String**
- `"Read state file failed: ~s: ~s"`
-
-
-
-
-
-
-SNMP_REQUIRES_CDB
- -SNMP_REQUIRES_CDB
-
-* **Severity**
- `WARNING`
-* **Description**
- The SNMP agent requires CDB to be enabled in order to be started.
-* **Format String**
- `"Can't start SNMP. CDB is not enabled"`
-
-
-
-
-
-
-SNMP_TRAP_NOT_FORWARDED
- -SNMP_TRAP_NOT_FORWARDED
-
-* **Severity**
- `INFO`
-* **Description**
- An SNMP trap was to be forwarded, but couldn't be.
-* **Format String**
- `"SNMP gateway: Can't forward trap from ~s; ~s"`
-
-
-
-
-
-
-SNMP_TRAP_NOT_RECOGNIZED
- -SNMP_TRAP_NOT_RECOGNIZED
-
-* **Severity**
- `INFO`
-* **Description**
- An SNMP trap was received on the trap receiving port, but its definition is not known
-* **Format String**
- `"SNMP gateway: Can't forward trap with OID ~s from ~s; There is no notification with this OID in the loaded models."`
-
-
-
-
-
-
-SNMP_TRAP_OPEN_PORT
- -SNMP_TRAP_OPEN_PORT
-
-* **Severity**
- `ERR`
-* **Description**
- The port for listening to SNMP traps could not be opened.
-* **Format String**
- `"SNMP gateway: Can't open trap listening port ~s: ~s"`
-
-
-
-
-
-
-SNMP_TRAP_UNKNOWN_SENDER
- -SNMP_TRAP_UNKNOWN_SENDER
-
-* **Severity**
- `INFO`
-* **Description**
- An SNMP trap was to be forwarded, but the sender was not listed in confd.conf.
-* **Format String**
- `"SNMP gateway: Not forwarding trap from ~s; the sender is not recognized"`
-
-
-
-
-
-
-SNMP_TRAP_V1
- -SNMP_TRAP_V1
-
-* **Severity**
- `INFO`
-* **Description**
- An SNMP v1 trap was received on the trap receiving port, but forwarding v1 traps is not supported.
-* **Format String**
- `"SNMP gateway: V1 trap received from ~s"`
-
-
-
-
-
-
-SNMP_WRITE_STATE_FILE_FAILED
- -SNMP_WRITE_STATE_FILE_FAILED
-
-* **Severity**
- `WARNING`
-* **Description**
- Write SNMP agent state file failed
-* **Format String**
- `"Write state file failed: ~s: ~s"`
-
-
-
-
-
-
-SSH_HOST_KEY_UNAVAILABLE
- -SSH_HOST_KEY_UNAVAILABLE
-
-* **Severity**
- `ERR`
-* **Description**
- No SSH host keys available.
-* **Format String**
- `"No SSH host keys available"`
-
-
-
-
-
-
-SSH_SUBSYS_ERR
- -SSH_SUBSYS_ERR
-
-* **Severity**
- `INFO`
-* **Description**
- Typically errors where the client doesn't properly send the \"subsystem\" command.
-* **Format String**
- `"ssh protocol subsys - ~s"`
-
-
-
-
-
-
-STARTED
- -STARTED
-
-* **Severity**
- `INFO`
-* **Description**
- ConfD has started.
-* **Format String**
- `"ConfD started vsn: ~s"`
-
-
-
-
-
-
-STARTING
- -STARTING
-
-* **Severity**
- `INFO`
-* **Description**
- ConfD is starting.
-* **Format String**
- `"Starting ConfD vsn: ~s"`
-
-
-
-
-
-
-STOPPING
- -STOPPING
-
-* **Severity**
- `INFO`
-* **Description**
- ConfD is stopping (due to e.g. confd --stop).
-* **Format String**
- `"ConfD stopping (~s)"`
-
-
-
-
-
-
-TOKEN_MISMATCH
- -TOKEN_MISMATCH
-
-* **Severity**
- `ERR`
-* **Description**
- A secondary connected to a primary with a bad auth token
-* **Format String**
- `"Token mismatch, secondary is not allowed"`
-
-
-
-
-
-
-UPGRADE_ABORTED
- -UPGRADE_ABORTED
-
-* **Severity**
- `INFO`
-* **Description**
- In-service upgrade was aborted.
-* **Format String**
- `"Upgrade aborted"`
-
-
-
-
-
-
-UPGRADE_COMMITTED
- -UPGRADE_COMMITTED
-
-* **Severity**
- `INFO`
-* **Description**
- In-service upgrade was committed.
-* **Format String**
- `"Upgrade committed"`
-
-
-
-
-
-
-UPGRADE_INIT_STARTED
- -UPGRADE_INIT_STARTED
-
-* **Severity**
- `INFO`
-* **Description**
- In-service upgrade initialization has started.
-* **Format String**
- `"Upgrade init started"`
-
-
-
-
-
-
-UPGRADE_INIT_SUCCEEDED
- -UPGRADE_INIT_SUCCEEDED
-
-* **Severity**
- `INFO`
-* **Description**
- In-service upgrade initialization succeeded.
-* **Format String**
- `"Upgrade init succeeded"`
-
-
-
-
-
-
-UPGRADE_PERFORMED
- -UPGRADE_PERFORMED
-
-* **Severity**
- `INFO`
-* **Description**
- In-service upgrade has been performed (not committed yet).
-* **Format String**
- `"Upgrade performed"`
-
-
-
-
-
-
-WEBUI_LOG_MSG
- -WEBUI_LOG_MSG
-
-* **Severity**
- `INFO`
-* **Description**
- WebUI access log message
-* **Format String**
- `"WebUI access log: ~s"`
-
-
-
-
-
-
-WEB_ACTION
- -WEB_ACTION
-
-* **Severity**
- `INFO`
-* **Description**
- User executed a Web UI action.
-* **Format String**
- `"WebUI action '~s'"`
-
-
-
-
-
-
-WEB_CMD
- -WEB_CMD
-
-* **Severity**
- `INFO`
-* **Description**
- User executed a Web UI command.
-* **Format String**
- `"WebUI cmd '~s'"`
-
-
-
-
-
-
-WEB_COMMIT
- -WEB_COMMIT
-
-* **Severity**
- `INFO`
-* **Description**
- User performed Web UI commit.
-* **Format String**
- `"WebUI commit ~s"`
-
-
-
-
-
-
-WRITE_STATE_FILE_FAILED
- -WRITE_STATE_FILE_FAILED
-
-* **Severity**
- `CRIT`
-* **Description**
- Writing of a state file failed
-* **Format String**
- `"Writing state file failed: ~s: ~s (~s)"`
-
-
-
-
-
-
-XPATH_EVAL_ERROR1
- -XPATH_EVAL_ERROR1
-
-* **Severity**
- `WARNING`
-* **Description**
- An error occurred while evaluating an XPath expression.
-* **Format String**
- `"XPath evaluation error: ~s for ~s"`
-
-
-
-
-
-
-XPATH_EVAL_ERROR2
- -XPATH_EVAL_ERROR2
-
-* **Severity**
- `WARNING`
-* **Description**
- An error occurred while evaluating an XPath expression.
-* **Format String**
- `"XPath evaluation error: '~s' resulted in ~s for ~s"`
-
-
-
-
-
-
-COMMIT_UN_SYNCED_DEV
- -COMMIT_UN_SYNCED_DEV
-
-* **Severity**
- `INFO`
-* **Description**
- Data was committed toward a device with bad or unknown sync state
-* **Format String**
- `"Committed data towards device ~s which is out of sync"`
-
-
-
-
-
-
-NCS_DEVICE_OUT_OF_SYNC
- -NCS_DEVICE_OUT_OF_SYNC
-
-* **Severity**
- `INFO`
-* **Description**
- A check-sync action reported out-of-sync for a device
-* **Format String**
- `"NCS device-out-of-sync Device '~s' Info '~s'"`
-
-
-
-
-
-
-NCS_JAVA_VM_FAIL
- -NCS_JAVA_VM_FAIL
-
-* **Severity**
- `ERR`
-* **Description**
- The NCS Java VM failure/timeout
-* **Format String**
- `"The NCS Java VM ~s"`
-
-
-
-
-
-
-NCS_JAVA_VM_START
- -NCS_JAVA_VM_START
-
-* **Severity**
- `INFO`
-* **Description**
- Starting the NCS Java VM
-* **Format String**
- `"Starting the NCS Java VM"`
-
-
-
-
-
-
-NCS_PACKAGE_AUTH_BAD_RET
- -NCS_PACKAGE_AUTH_BAD_RET
-
-* **Severity**
- `ERR`
-* **Description**
- Package authentication program returned badly formatted data.
-* **Format String**
- `"package authentication using ~s program ret bad output: ~s"`
-
-
-
-
-
-
-NCS_PACKAGE_AUTH_FAIL
- -NCS_PACKAGE_AUTH_FAIL
-
-* **Severity**
- `INFO`
-* **Description**
- Package authentication failed.
-* **Format String**
- `"package authentication using ~s failed via ~s from ~s with ~s: ~s"`
-
-
-
-
-
-
-NCS_PACKAGE_AUTH_SUCCESS
- -NCS_PACKAGE_AUTH_SUCCESS
-
-* **Severity**
- `INFO`
-* **Description**
- A package authenticated user logged in.
-* **Format String**
- `"package authentication using ~s succeeded via ~s from ~s with ~s, member of groups: ~s~s"`
-
-
-
-
-
-
-NCS_PACKAGE_BAD_DEPENDENCY
- -NCS_PACKAGE_BAD_DEPENDENCY
-
-* **Severity**
- `CRIT`
-* **Description**
- Bad NCS package dependency
-* **Format String**
- `"Failed to load NCS package: ~s; required package ~s of version ~s is not present (found ~s)"`
-
-
-
-
-
-
-NCS_PACKAGE_BAD_NCS_VERSION
- -NCS_PACKAGE_BAD_NCS_VERSION
-
-* **Severity**
- `CRIT`
-* **Description**
- Bad NCS version for package
-* **Format String**
- `"Failed to load NCS package: ~s; requires NCS version ~s"`
-
-
-
-
-
-
-NCS_PACKAGE_CHAL_2FA
- -NCS_PACKAGE_CHAL_2FA
-
-* **Severity**
- `INFO`
-* **Description**
- Package authentication challenge sent to a user.
-* **Format String**
- `"package authentication challenge sent to ~s from ~s with ~s"`
-
-
-
-
-
-
-NCS_PACKAGE_CHAL_FAIL
- -NCS_PACKAGE_CHAL_FAIL
-
-* **Severity**
- `INFO`
-* **Description**
- Package authentication challenge failed.
-* **Format String**
- `"package authentication challenge using ~s failed via ~s from ~s with ~s: ~s"`
-
-
-
-
-
-
-NCS_PACKAGE_CIRCULAR_DEPENDENCY
- -NCS_PACKAGE_CIRCULAR_DEPENDENCY
-
-* **Severity**
- `CRIT`
-* **Description**
- Circular NCS package dependency
-* **Format String**
- `"Failed to load NCS package: ~s; circular dependency found"`
-
-
-
-
-
-
-NCS_PACKAGE_COPYING
- -NCS_PACKAGE_COPYING
-
-* **Severity**
- `DEBUG`
-* **Description**
- A package is copied from the load path to private directory
-* **Format String**
- `"Copying NCS package from ~s to ~s"`
-
-
-
-
-
-
-NCS_PACKAGE_DUPLICATE
- -NCS_PACKAGE_DUPLICATE
-
-* **Severity**
- `CRIT`
-* **Description**
- Duplicate package found
-* **Format String**
- `"Failed to load duplicate NCS package ~s: (~s)"`
-
-
-
-
-
-
-NCS_PACKAGE_STATUS_CHANGE
- -NCS_PACKAGE_STATUS_CHANGE
-
-* **Severity**
- `DEBUG`
-* **Description**
- Status changed for the given package.
-* **Format String**
- `"package '~s' status changed to '~s'."`
-
-
-
-
-
-
-NCS_PACKAGE_SYNTAX_ERROR
- -NCS_PACKAGE_SYNTAX_ERROR
-
-* **Severity**
- `CRIT`
-* **Description**
- Syntax error in package file
-* **Format String**
- `"Failed to load NCS package: ~s; syntax error in package file"`
-
-
-
-
-
-
-NCS_PACKAGE_UPGRADE_ABORTED
- -NCS_PACKAGE_UPGRADE_ABORTED
-
-* **Severity**
- `CRIT`
-* **Description**
- The CDB upgrade was aborted implying that CDB is untouched. However the package state is changed
-* **Format String**
- `"NCS package upgrade failed with reason '~s'"`
-
-
-
-
-
-
-NCS_PACKAGE_UPGRADE_UNSAFE
- -NCS_PACKAGE_UPGRADE_UNSAFE
-
-* **Severity**
- `CRIT`
-* **Description**
- Package upgrade has been aborted due to warnings.
-* **Format String**
- `"NCS package upgrade has been aborted due to warnings:\n~s"`
-
-
-
-
-
-
-NCS_PYTHON_VM_FAIL
- -NCS_PYTHON_VM_FAIL
-
-* **Severity**
- `ERR`
-* **Description**
- The NCS Python VM failure/timeout
-* **Format String**
- `"The NCS Python VM ~s"`
-
-
-
-
-
-
-NCS_PYTHON_VM_START
- -NCS_PYTHON_VM_START
-
-* **Severity**
- `INFO`
-* **Description**
- Starting the named NCS Python VM
-* **Format String**
- `"Starting the NCS Python VM ~s"`
-
-
-
-
-
-
-NCS_PYTHON_VM_START_UPGRADE
- -NCS_PYTHON_VM_START_UPGRADE
-
-* **Severity**
- `INFO`
-* **Description**
- Starting a Python VM to run upgrade code
-* **Format String**
- `"Starting upgrade of NCS Python package ~s"`
-
-
-
-
-
-
-NCS_SERVICE_OUT_OF_SYNC
- -NCS_SERVICE_OUT_OF_SYNC
-
-* **Severity**
- `INFO`
-* **Description**
- A check-sync action reported out-of-sync for a service
-* **Format String**
- `"NCS service-out-of-sync Service '~s' Info '~s'"`
-
-
-
-
-
-
-NCS_SET_PLATFORM_DATA_ERROR
- -NCS_SET_PLATFORM_DATA_ERROR
-
-* **Severity**
- `ERR`
-* **Description**
- The device failed to set the platform operational data at connect
-* **Format String**
- `"NCS Device '~s' failed to set platform data Info '~s'"`
-
-
-
-
-
-
-NCS_SMART_LICENSING_ENTITLEMENT_NOTIFICATION
- -NCS_SMART_LICENSING_ENTITLEMENT_NOTIFICATION
-
-* **Severity**
- `INFO`
-* **Description**
- Smart Licensing Entitlement Notification
-* **Format String**
- `"Smart Licensing Entitlement Notification: ~s"`
-
-
-
-
-
-
-NCS_SMART_LICENSING_EVALUATION_COUNTDOWN
- -NCS_SMART_LICENSING_EVALUATION_COUNTDOWN
-
-* **Severity**
- `INFO`
-* **Description**
- Smart Licensing evaluation time remaining
-* **Format String**
- `"Smart Licensing evaluation time remaining: ~s"`
-
-
-
-
-
-
-NCS_SMART_LICENSING_FAIL
- -NCS_SMART_LICENSING_FAIL
-
-* **Severity**
- `INFO`
-* **Description**
- The NCS Smart Licensing Java VM failure/timeout
-* **Format String**
- `"The NCS Smart Licensing Java VM ~s"`
-
-
-
-
-
-
-NCS_SMART_LICENSING_GLOBAL_NOTIFICATION
- -NCS_SMART_LICENSING_GLOBAL_NOTIFICATION
-
-* **Severity**
- `INFO`
-* **Description**
- Smart Licensing Global Notification
-* **Format String**
- `"Smart Licensing Global Notification: ~s"`
-
-
-
-
-
-
-NCS_SMART_LICENSING_START
- -NCS_SMART_LICENSING_START
-
-* **Severity**
- `INFO`
-* **Description**
- Starting the NCS Smart Licensing Java VM
-* **Format String**
- `"Starting the NCS Smart Licensing Java VM"`
-
-
-
-
-
-
-NCS_SNMPM_START
- -NCS_SNMPM_START
-
-* **Severity**
- `INFO`
-* **Description**
- Starting the NCS SNMP manager component
-* **Format String**
- `"Starting the NCS SNMP manager component"`
-
-
-
-
-
-
-NCS_SNMPM_STOP
- -NCS_SNMPM_STOP
-
-* **Severity**
- `INFO`
-* **Description**
- The NCS SNMP manager component has been stopped
-* **Format String**
- `"The NCS SNMP manager component has been stopped"`
-
-
-
-
-
-
-NCS_SNMP_INIT_ERR
- -NCS_SNMP_INIT_ERR
-
-* **Severity**
- `INFO`
-* **Description**
- Failed to locate snmp_init.xml in loadpath
-* **Format String**
- `"Failed to locate snmp_init.xml in loadpath ~s"`
-
-
-
-
-
-
-NCS_UPGRADE_ABORTED_INTERNAL
- -NCS_UPGRADE_ABORTED_INTERNAL
-
-* **Severity**
- `CRIT`
-* **Description**
- The CDB upgrade was aborted due to some internal error. CDB is left untouched
-* **Format String**
- `"NCS upgrade failed with reason '~s'"`
-
-
-
-
-
-
-BAD_LOCAL_PASS
- -BAD_LOCAL_PASS
-
-* **Severity**
- `INFO`
-* **Description**
- A locally configured user provided a bad password.
-* **Format String**
- `"Provided bad password"`
-
-
-
-
-
-
-EXT_LOGIN
- -EXT_LOGIN
-
-* **Severity**
- `INFO`
-* **Description**
- An externally authenticated user logged in.
-* **Format String**
- `"Logged in over ~s using externalauth, member of groups: ~s~s"`
-
-
-
-
-
-
-EXT_NO_LOGIN
- -EXT_NO_LOGIN
-
-* **Severity**
- `INFO`
-* **Description**
- External authentication failed for a user.
-* **Format String**
- `"failed to login using externalauth: ~s"`
-
-
-
-
-
-
-NO_SUCH_LOCAL_USER
- -NO_SUCH_LOCAL_USER
-
-* **Severity**
- `INFO`
-* **Description**
- A non existing local user tried to login.
-* **Format String**
- `"no such local user"`
-
-
-
-
-
-
-PAM_LOGIN_FAILED
- -PAM_LOGIN_FAILED
-
-* **Severity**
- `INFO`
-* **Description**
- A user failed to login through PAM.
-* **Format String**
- `"pam phase ~s failed to login through PAM: ~s"`
-
-
-
-
-
-
-PAM_NO_LOGIN
- -PAM_NO_LOGIN
-
-* **Severity**
- `INFO`
-* **Description**
- A user failed to login through PAM
-* **Format String**
- `"failed to login through PAM: ~s"`
-
-
-
-
-
-
-SSH_LOGIN
- -SSH_LOGIN
-
-* **Severity**
- `INFO`
-* **Description**
- A user logged into ConfD's builtin ssh server.
-* **Format String**
- `"logged in over ssh from ~s with authmeth:~s"`
-
-
-
-
-
-
-SSH_LOGOUT
- -SSH_LOGOUT
-
-* **Severity**
- `INFO`
-* **Description**
- A user was logged out from ConfD's builtin ssh server.
-* **Format String**
- `"Logged out ssh <~s> user"`
-
-
-
-
-
-
-SSH_NO_LOGIN
- -SSH_NO_LOGIN
-
-* **Severity**
- `INFO`
-* **Description**
- A user failed to login to ConfD's builtin SSH server.
-* **Format String**
- `"Failed to login over ssh: ~s"`
-
-
-
-
-
-
-WEB_LOGIN
- -WEB_LOGIN
-
-* **Severity**
- `INFO`
-* **Description**
- A user logged in through the WebUI.
-* **Format String**
- `"logged in through Web UI from ~s"`
-
-
-
-
-
diff --git a/best-practices/network-automation-delivery-model.md b/best-practices/network-automation-delivery-model.md
new file mode 100644
index 00000000..67afc7b1
--- /dev/null
+++ b/best-practices/network-automation-delivery-model.md
@@ -0,0 +1,10 @@
+---
+description: Learn how to build an automation practice.
+icon: space-awesome
+---
+
+# Network Automation Delivery Model
+
+Visit the link below to learn more.
+
+{% embed url="https://developer.cisco.com/docs/network-automation-delivery-model/network-automation-delivery-model/" %}
diff --git a/best-practices/nso-on-kubernetes.md b/best-practices/nso-on-kubernetes.md
new file mode 100644
index 00000000..fa10e65e
--- /dev/null
+++ b/best-practices/nso-on-kubernetes.md
@@ -0,0 +1,120 @@
+---
+icon: spider-web
+description: Best practice guidelines for deploying NSO on Kubernetes.
+---
+
+# NSO on Kubernetes
+
+Deploying Cisco NSO on Kubernetes offers numerous advantages, including consistent deployments, self-healing capabilities, and better version control. This document outlines best practices for deploying NSO on Kubernetes to ensure optimal performance, security, and maintainability.
+
+{% hint style="success" %}
+See also the documentation for the Cisco-provided [Containerized NSO](https://cisco-tailf.gitbook.io/nso-docs/guides/administration/installation-and-deployment/containerized-nso) images.
+{% endhint %}
+
+## Prerequisites
+
+### Kubernetes Cluster
+
+* **Version Compatibility**: Ensure that your Kubernetes cluster is within the three most recent minor releases to maintain official support.
+* **Persistent Storage**: Install a Container Storage Interface (CSI) if not using a managed Kubernetes service. Managed services like EKS on AWS or GKE on GCP handle this automatically.
+* **Networking**: Install a Container Network Interface (CNI) such as Cilium, Calico, Flannel, or Weave. Additionally, configure an ingress controller or load balancer as needed to expose services.
+* **TLS Certificates**: Use TLS certificates for HTTPS access and to secure communication between different NSO instances. This is crucial for securing data transmission.
+
+## Deployment Architecture
+
+### Namespace Design
+
+* **Isolation**: Run NSO in its own namespace to isolate its resources (pods, services, secrets, and so on.) from other applications and services in the cluster. This logical separation helps manage resources and apply specific RBAC policies.
+
+### Pod Design
+
+* **Stateful Pods**: Use StatefulSets for production deployments to ensure that each NSO pod retains its data across restarts by mounting the same PersistentVolume. StatefulSets also provide a stable network identity for each pod.
+* **Data Persistence**: Attach persistent volumes to NSO pods to ensure data persistence. Avoid using hostPath volumes in production due to security risks.
+
+### Service Design
+
+* **Service Types**:
+ * **ClusterIP**: Use for internal communications between NSO instances or other Kubernetes resources.
+ * **NodePort**: Use for testing purposes only, as it exposes pods over the address of a Kubernetes node.
+ * **LoadBalancer**: Use for external access, such as exposing SSH/NETCONF ports.
+* **Ingress Controllers**: Use Ingress for managing external access to HTTP or HTTPS traffic. For more advanced routing capabilities, consider using the Gateway API.
+
+## Storage Design
+
+### Volume Management
+
+* **Persistent Volumes**: Use PersistentVolumeClaims to manage storage and ensure that critical directories like NSO running directory, packages directory, and logs directory persist through restarts.
+* **NSO Directories**: Mount necessary directories, such as the NSO running directory, packages directory, and logs directory to persistent volumes.
+* **Avoid HostPath**: Refrain from using hostPath volumes in production environments, as they expose NSO data to the host system and add maintenance overhead.
+
+## Deployment Strategies
+
+### YAML Manifests
+
+* **Version Control**: Define Kubernetes objects using YAML manifests and manage them via version control. This ensures consistent deployments and easier rollback capabilities.
+* **ConfigMaps and Secrets**: Use ConfigMaps for non-sensitive configuration files and Secrets for sensitive data like Docker registry credentials. ConfigMaps are used to manage NSO configuration files, while Secrets can store sensitive information such as passwords and API keys. In NSO, the sensitive data that should go into Secrets is, for example, encryption keys for the CDB.
+
+### Helm Charts
+
+* **Simplified Deployment**: Use Helm charts for packaging YAML manifests, simplifying the deployment process. Manage deployment parameters through a `values.yaml` file.
+* **Custom Configuration**: Expose runtime parameters, service ports, URLs, and other configurations via Helm templates. Helm charts allow for more dynamic and reusable configurations.
+
+## Security Considerations
+
+### Running as Non-Root
+
+* **SecurityContext**: Limit the Linux capabilities that are allowed for the NSO container and avoid running containers as the root user. This can be done by defining a SecurityContext in the Pod specification.
+* **Custom Dockerfile**: Create a Dockerfile to add a non-root user and adjust folder permissions, ensuring NSO runs as a dedicated user. This can help in adhering to the principle of least privilege.
+
+### Network Policies
+
+* **Ingress and Egress Control**: Implement network policies to restrict access to NSO instances and managed devices. Limit the communication to trusted IP ranges and namespaces.
+* **Service Accounts**: Create dedicated service accounts for NSO pods to minimize permissions and reduce security risks. This ensures that each service account only has the permissions it needs for its tasks.
+
+## Monitoring & Logging
+
+### Observability Exporter
+
+* **Setup**: Transform Docker Compose files to Kubernetes manifests using tools like Kompose. Deploy the observability exporter to export data in industry-standard formats such as OpenTelemetry.
+* **Container Probes**: Implement readiness probes to monitor the health and readiness of NSO containers. Use HTTP checks to ensure that the NSO API is operational. Probes can help in ensuring that the application is functioning correctly and can handle traffic.
+
+## Scaling & Performance Optimization
+
+### Resource Requests & Limits
+
+* **Resource Management**: Define resource requests and limits for NSO pods to ensure appropriate CPU and memory allocation. This helps maintain cluster stability and performance by preventing any single pod from using excessive resources.
+
+### Affinity & Anti-Affinity
+
+* **Pod Distribution**: Use affinity and anti-affinity rules to ensure optimal distribution of NSO pods across worker nodes. This helps in achieving high availability and resilience by ensuring that pods are evenly distributed across nodes.
+
+## High Availability & Resiliency
+
+### Raft HA
+
+* **Setup**: Configure a three-node Raft cluster for high availability. Ensure that each node has a unique pod and network identity, as well as its own PersistentVolume and PersistentVolumeClaim.
+* **Annotations**: Use annotations to direct requests to the primary NSO instance. Implement sidecar containers to periodically check and update the Raft HA status. This ensures that the primary instance is always up and running.
+
+## Backup & Disaster Recovery
+
+### NSO Backup
+
+* **Automated Backups**: Use Kubernetes CronJobs to automate regular NSO backups. Store the backups securely and periodically verify them.
+* **Disaster Recovery**: Ensure that NSO backups are stored in a secure location and can be restored in case of cluster failure. Use temporary container instances to restore backups without running NSO.
+
+## Upgrade & Maintenance
+
+### Upgrading NSO
+
+* **Persistent Storage**: Ensure that the NSO running directory uses persistent storage to maintain data integrity during upgrades.
+* **Testing**: Test upgrades on a dummy instance before applying them to production. Clone the existing PVC and spin up a new NSO instance for testing.
+* **Rolling Upgrades**: Update the container image version in YAML manifests or Helm charts. Delete the old NSO pods to allow Kubernetes to deploy the new ones. This minimizes downtime and ensures a smooth transition to the new version.
+
+### Cluster Maintenance
+
+* **Rolling Upgrades**: Perform rolling node upgrades to minimize downtime and ensure high availability. Ensure the compatibility with Kubernetes API and resource definitions before upgrading.
+* **Node Draining**: Drain and cordon nodes to safely migrate NSO instances during maintenance. This helps in ensuring that the cluster remains functional during maintenance activities.
+
+## Conclusion
+
+By adhering to these best practices, you can ensure a robust, secure, and efficient deployment of Cisco NSO on Kubernetes. These guidelines help maintain operational stability, improve performance, and enhance the overall manageability of your Kubernetes deployments. Implementing these practices will help in achieving a reliable and scalable Kubernetes environment for NSO.
diff --git a/best-practices/scaling-and-performance-optimization.md b/best-practices/scaling-and-performance-optimization.md
new file mode 100644
index 00000000..8c98ba05
--- /dev/null
+++ b/best-practices/scaling-and-performance-optimization.md
@@ -0,0 +1,10 @@
+---
+description: Optimize NSO for scaling and performance.
+icon: chart-mixed
+---
+
+# Scaling and Performance Optimization
+
+Visit the link below to learn more.
+
+{% embed url="https://cisco-tailf.gitbook.io/nso-docs/guides/development/advanced-development/scaling-and-performance-optimization" %}
diff --git a/developer-reference/erlang-api-reference.md b/developer-reference/erlang-api-reference.md
deleted file mode 100644
index 22d2714c..00000000
--- a/developer-reference/erlang-api-reference.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-description: NSO Erlang API Reference.
-icon: square-e
----
-
-# Erlang API Reference
-
-Visit the link below to learn more.
-
-{% embed url="https://developer.cisco.com/docs/nso-api-6.5/nso-erlang-api-api-overview/" %}
diff --git a/developer-reference/erlang/README.md b/developer-reference/erlang/README.md
deleted file mode 100644
index 8b06aad4..00000000
--- a/developer-reference/erlang/README.md
+++ /dev/null
@@ -1,57 +0,0 @@
----
-icon: square-e
----
-
-# Erlang API Reference
-
-The `econfd` application is the Erlang API towards the ConfD daemon. It is delivered as an OTP application, which must be started by the system which wishes to interface to ConfD. As an alternative, the supervisor `econfd_sup` can be started directly.
-
-This is the equivalent of libconfd.so for C programmers.
-
-The interface towards ConfD is a socket based IPC interface, thus this application, econfd, executes in a different address space than ConfD itself. The protocol between econfd and ConfD is almost the same regardless of whether econfd (erlang API) or libconfd.so (C API) is used.
-
-Thus the architecture is according to the following picture:
-
-WEB_LOGOUT
- -WEB_LOGOUT
-
-* **Severity**
- `INFO`
-* **Description**
- A Web UI user logged out.
-* **Format String**
- `"logged out from Web UI"`
-
-
Architecture
-
-
-
-did(...)
- -Method: - -```python -did() -> int -``` - -
-
-
-
-dx(...)
- -Method: - -```python -dx() -> DaemonCtxRef -``` - -
-
-
-
-lastop(...)
- -Method: - -```python -lastop() -> int -``` - -
-
-
-
-qref(...)
- -Method: - -```python -qref() -> int -``` - -
-
-
-
-### _class_ **ListFilter**
-
-This type represents the c-type struct confd\_list\_filter.
-
-Available attributes:
-
-* type -- filter type, LF\_\*
-* expr1 -- OR, AND, NOT expression
-* expr2 -- OR, AND expression
-* op -- operation, CMP\_\* and EXEC\_\*
-* node -- filter tagpath
-* val -- filter value
-
-ListFilter cannot be directly instantiated from Python.
-
-Members:
-
-_None_
-
-### _class_ **NotificationCtxRef**
-
-This type represents the c-type struct confd\_notification\_ctx.
-
-Available attributes:
-
-* name -- stream name or snmp notify name (string or None)
-* ctx\_name -- for snmp only (string or None)
-* fd -- worker socket (int)
-* dx -- the daemon context (DaemonCtxRef)
-
-NotificationCtxRef cannot be directly instantiated from Python.
-
-Members:
-
-_None_
-
-### _class_ **TrItemRef**
-
-This type represents the c-type confd\_tr\_item.
-
-Available attributes:
-
-* callpoint -- the callpoint (string)
-* op -- operation, one of C\_SET\_ELEM, C\_CREATE, C\_REMOVE, C\_SET\_CASE, C\_SET\_ATTR or C\_MOVE\_AFTER (int)
-* hkp -- the keypath (HKeypathRef)
-* val -- the value (Value or None)
-* choice -- the choice, only for C\_SET\_CASE (Value or None)
-* attr -- attribute, only for C\_SET\_ATTR (int or None)
-* next -- the next TrItemRef object in the linked list or None if no more items are found
-
-TrItemRef cannot be directly instantiated from Python.
-
-Members:
-
-_None_
-
-## Predefined Values
-
-```python
-
-ACCESS_CHK_DESCENDANT = 1024
-ACCESS_CHK_FINAL = 512
-ACCESS_CHK_INTERMEDIATE = 256
-ACCESS_OP_CREATE = 4
-ACCESS_OP_DELETE = 16
-ACCESS_OP_EXECUTE = 2
-ACCESS_OP_READ = 1
-ACCESS_OP_UPDATE = 8
-ACCESS_OP_WRITE = 32
-ACCESS_RESULT_ACCEPT = 0
-ACCESS_RESULT_CONTINUE = 2
-ACCESS_RESULT_DEFAULT = 3
-ACCESS_RESULT_REJECT = 1
-BAD_VALUE_BAD_KEY_TAG = 32
-BAD_VALUE_BAD_LEXICAL = 19
-BAD_VALUE_BAD_TAG = 21
-BAD_VALUE_BAD_VALUE = 20
-BAD_VALUE_CUSTOM_FACET_ERROR_MESSAGE = 16
-BAD_VALUE_ENUMERATION = 11
-BAD_VALUE_FRACTION_DIGITS = 3
-BAD_VALUE_INVALID_FACET = 18
-BAD_VALUE_INVALID_REGEX = 9
-BAD_VALUE_INVALID_TYPE_NAME = 23
-BAD_VALUE_INVALID_UTF8 = 38
-BAD_VALUE_INVALID_XPATH = 34
-BAD_VALUE_INVALID_XPATH_AT_TAG = 40
-BAD_VALUE_INVALID_XPATH_PATH = 39
-BAD_VALUE_LENGTH = 15
-BAD_VALUE_MAX_EXCLUSIVE = 5
-BAD_VALUE_MAX_INCLUSIVE = 6
-BAD_VALUE_MAX_LENGTH = 14
-BAD_VALUE_MIN_EXCLUSIVE = 7
-BAD_VALUE_MIN_INCLUSIVE = 8
-BAD_VALUE_MIN_LENGTH = 13
-BAD_VALUE_MISSING_KEY = 37
-BAD_VALUE_MISSING_NAMESPACE = 27
-BAD_VALUE_NOT_RESTRICTED_XPATH = 35
-BAD_VALUE_NO_DEFAULT_NAMESPACE = 24
-BAD_VALUE_PATTERN = 12
-BAD_VALUE_POP_TOO_FAR = 31
-BAD_VALUE_RANGE = 29
-BAD_VALUE_STRING_FUN = 1
-BAD_VALUE_SYMLINK_BAD_KEY_REFERENCE = 33
-BAD_VALUE_TOTAL_DIGITS = 4
-BAD_VALUE_UNIQUELIST = 10
-BAD_VALUE_UNKNOWN_BIT_LABEL = 22
-BAD_VALUE_UNKNOWN_NAMESPACE = 26
-BAD_VALUE_UNKNOWN_NAMESPACE_PREFIX = 25
-BAD_VALUE_USER_ERROR = 17
-BAD_VALUE_VALUE2VALUE_FUN = 28
-BAD_VALUE_WRONG_DECIMAL64_FRACTION_DIGITS = 2
-BAD_VALUE_WRONG_NUMBER_IDENTIFIERS = 30
-BAD_VALUE_XPATH_ERROR = 36
-CLI_ACTION_NOT_FOUND = 13
-CLI_AMBIGUOUS_COMMAND = 63
-CLI_BAD_ACTION_RESPONSE = 16
-CLI_BAD_LEAF_VALUE = 6
-CLI_CDM_NOT_SUPPORTED = 74
-CLI_COMMAND_ABORTED = 2
-CLI_COMMAND_ERROR = 1
-CLI_COMMAND_FAILED = 3
-CLI_CONFIRMED_NOT_SUPPORTED = 39
-CLI_COPY_CONFIG_FAILED = 32
-CLI_COPY_FAILED = 31
-CLI_COPY_PATH_IDENTICAL = 33
-CLI_CREATE_PATH = 23
-CLI_CUSTOM_ERROR = 4
-CLI_DELETE_ALL_FAILED = 10
-CLI_DELETE_ERROR = 12
-CLI_DELETE_FAILED = 11
-CLI_ELEMENT_DOES_NOT_EXIST = 66
-CLI_ELEMENT_MANDATORY = 75
-CLI_ELEMENT_NOT_FOUND = 14
-CLI_ELEM_NOT_WRITABLE = 7
-CLI_EXPECTED_BOL = 56
-CLI_EXPECTED_EOL = 57
-CLI_FAILED_COPY_RUNNING = 38
-CLI_FAILED_CREATE_CONTEXT = 37
-CLI_FAILED_OPEN_STARTUP = 41
-CLI_FAILED_OPEN_STARTUP_CONFIG = 42
-CLI_FAILED_TERM_REDIRECT = 49
-CLI_ILLEGAL_DIRECTORY_NAME = 52
-CLI_ILLEGAL_FILENAME = 53
-CLI_INCOMPLETE_CMD_PATH = 67
-CLI_INCOMPLETE_COMMAND = 9
-CLI_INCOMPLETE_PATH = 8
-CLI_INCOMPLETE_PATTERN = 64
-CLI_INVALID_PARAMETER = 54
-CLI_INVALID_PASSWORD = 21
-CLI_INVALID_PATH = 58
-CLI_INVALID_ROLLBACK_NR = 15
-CLI_INVALID_SELECT = 59
-CLI_MESSAGE_TOO_LARGE = 48
-CLI_MISSING_ACTION_PARAM = 17
-CLI_MISSING_ACTION_PARAM_VALUE = 18
-CLI_MISSING_ARGUMENT = 69
-CLI_MISSING_DISPLAY_GROUP = 55
-CLI_MISSING_ELEMENT = 65
-CLI_MISSING_VALUE = 68
-CLI_MOVE_FAILED = 30
-CLI_MUST_BE_AN_INTEGER = 70
-CLI_MUST_BE_INTEGER = 43
-CLI_MUST_BE_TRUE_OR_FALSE = 71
-CLI_NOT_ALLOWED = 5
-CLI_NOT_A_DIRECTORY = 50
-CLI_NOT_A_FILE = 51
-CLI_NOT_FOUND = 28
-CLI_NOT_SUPPORTED = 34
-CLI_NOT_WRITABLE = 27
-CLI_NO_SUCH_ELEMENT = 45
-CLI_NO_SUCH_SESSION = 44
-CLI_NO_SUCH_USER = 47
-CLI_ON_LINE = 25
-CLI_ON_LINE_DESC = 26
-CLI_OPEN_FILE = 20
-CLI_READ_ERROR = 19
-CLI_REALLOCATE = 24
-CLI_SENSITIVE_DATA = 73
-CLI_SET_FAILED = 29
-CLI_START_REPLAY_FAILED = 72
-CLI_TARGET_EXISTS = 35
-CLI_UNKNOWN_ARGUMENT = 61
-CLI_UNKNOWN_COMMAND = 62
-CLI_UNKNOWN_ELEMENT = 60
-CLI_UNKNOWN_HIDEGROUP = 22
-CLI_UNKNOWN_MODE = 36
-CLI_WILDCARD_NOT_ALLOWED = 46
-CLI_WRITE_CONFIG_FAILED = 40
-COMPLETION = 0
-COMPLETION_DEFAULT = 3
-COMPLETION_DESC = 2
-COMPLETION_INFO = 1
-CONTROL_SOCKET = 0
-C_CREATE = 2
-C_MOVE_AFTER = 6
-C_REMOVE = 3
-C_SET_ATTR = 5
-C_SET_CASE = 4
-C_SET_ELEM = 1
-DAEMON_FLAG_BULK_GET_CONTAINER = 128
-DAEMON_FLAG_NO_DEFAULTS = 4
-DAEMON_FLAG_PREFER_BULK_GET = 64
-DAEMON_FLAG_REG_DONE = 65536
-DAEMON_FLAG_REG_REPLACE_DISCONNECT = 16
-DAEMON_FLAG_SEND_IKP = 1
-DAEMON_FLAG_STRINGSONLY = 2
-DATA_AFTER = 1
-DATA_BEFORE = 0
-DATA_CREATE = 0
-DATA_DELETE = 1
-DATA_FIRST = 2
-DATA_INSERT = 2
-DATA_LAST = 3
-DATA_MERGE = 3
-DATA_MOVE = 4
-DATA_REMOVE = 6
-DATA_REPLACE = 5
-DATA_WANT_FILTER = 1
-ERRTYPE_BAD_VALUE = 2
-ERRTYPE_CLI = 4
-ERRTYPE_MISC = 8
-ERRTYPE_NCS = 16
-ERRTYPE_OPERATION = 32
-ERRTYPE_VALIDATION = 1
-MISC_ACCESS_DENIED = 5
-MISC_APPLICATION = 19
-MISC_APPLICATION_INTERNAL = 20
-MISC_BAD_PERSIST_ID = 16
-MISC_CANDIDATE_ABORT_BAD_USID = 17
-MISC_CDB_OPER_UNAVAILABLE = 37
-MISC_DATA_MISSING = 44
-MISC_EXTERNAL = 22
-MISC_EXTERNAL_TIMEOUT = 45
-MISC_FILE_ACCESS_PATH = 33
-MISC_FILE_BAD_PATH = 34
-MISC_FILE_BAD_VALUE = 35
-MISC_FILE_CORRUPT = 52
-MISC_FILE_CREATE_PATH = 29
-MISC_FILE_DELETE_PATH = 32
-MISC_FILE_EOF = 36
-MISC_FILE_MOVE_PATH = 30
-MISC_FILE_OPEN_ERROR = 27
-MISC_FILE_SET_PATH = 31
-MISC_FILE_SYNTAX_ERROR = 28
-MISC_FILE_SYNTAX_ERROR_1 = 26
-MISC_HA_ABORT = 55
-MISC_INCONSISTENT_VALUE = 7
-MISC_INDEXED_VIEW_LIST_HOLE = 46
-MISC_INDEXED_VIEW_LIST_TOO_BIG = 18
-MISC_INTERNAL = 21
-MISC_INTERRUPT = 10
-MISC_IN_USE = 3
-MISC_LOCKED_BY = 4
-MISC_MISSING_INSTANCE = 8
-MISC_NODE_IS_READONLY = 13
-MISC_NODE_WAS_READONLY = 14
-MISC_NOT_IMPLEMENTED = 43
-MISC_NO_SUCH_FILE = 2
-MISC_OPERATION_NOT_SUPPORTED = 38
-MISC_PROTO_USAGE = 23
-MISC_REACHED_MAX_RETRIES = 56
-MISC_RESOLVE_NEEDED = 53
-MISC_RESOURCE_DENIED = 6
-MISC_ROLLBACK_DISABLED = 1
-MISC_ROTATE_LIST_KEY = 58
-MISC_SNMP_BAD_INDEX = 42
-MISC_SNMP_BAD_VALUE = 41
-MISC_SNMP_ERROR = 39
-MISC_SNMP_TIMEOUT = 40
-MISC_SUBAGENT_DOWN = 24
-MISC_SUBAGENT_ERROR = 25
-MISC_TOO_MANY_SESSIONS = 11
-MISC_TOO_MANY_TRANSACTIONS = 12
-MISC_TRANSACTION_CONFLICT = 54
-MISC_UNSUPPORTED_XML_ENCODING = 57
-MISC_UPGRADE_IN_PROGRESS = 15
-MISC_WHEN_FAILED = 9
-MISC_XPATH_COMPILE = 51
-NCS_BAD_AUTHGROUP_CALLBACK_RESPONSE = 104
-NCS_BAD_CAPAS = 14
-NCS_CALL_HOME = 107
-NCS_CLI_LOAD = 19
-NCS_COMMIT_QUEUED = 20
-NCS_COMMIT_QUEUED_AND_DELETED = 113
-NCS_COMMIT_QUEUE_DISABLED = 111
-NCS_COMMIT_QUEUE_HAS_OVERLAPPING = 103
-NCS_COMMIT_QUEUE_HAS_SENTINEL = 75
-NCS_CONFIG_LOCKED = 84
-NCS_CONFLICTING_INTENT = 125
-NCS_CONNECTION_CLOSED = 10
-NCS_CONNECTION_REFUSED = 5
-NCS_CONNECTION_TIMEOUT = 8
-NCS_CQ_BLOCK_OTHERS = 21
-NCS_CQ_REMOTE_NOT_ENABLED = 22
-NCS_DEV_AUTH_FAILED = 1
-NCS_DEV_IN_USE = 81
-NCS_HOST_LOOKUP = 12
-NCS_LOCKED = 3
-NCS_NCS_ACTION_NO_TRANSACTION = 67
-NCS_NCS_ALREADY_EXISTS = 82
-NCS_NCS_CLUSTER_AUTH_FAILED = 74
-NCS_NCS_DEV_ERROR = 69
-NCS_NCS_ERROR = 68
-NCS_NCS_ERROR_IKP = 70
-NCS_NCS_LOAD_TEMPLATE_COPY_TREE_CROSS_NS = 96
-NCS_NCS_LOAD_TEMPLATE_DUPLICATE_MACRO = 119
-NCS_NCS_LOAD_TEMPLATE_EOF_XML = 33
-NCS_NCS_LOAD_TEMPLATE_EXTRA_MACRO_VARS = 118
-NCS_NCS_LOAD_TEMPLATE_INVALID_CBTYPE = 128
-NCS_NCS_LOAD_TEMPLATE_INVALID_PI_REGEX = 122
-NCS_NCS_LOAD_TEMPLATE_INVALID_PI_SYNTAX = 86
-NCS_NCS_LOAD_TEMPLATE_INVALID_VALUE_XML = 30
-NCS_NCS_LOAD_TEMPLATE_MISPLACED_IF_NED_ID_MATCH_XML = 121
-NCS_NCS_LOAD_TEMPLATE_MISPLACED_IF_NED_ID_XML = 110
-NCS_NCS_LOAD_TEMPLATE_MISSING_ELEMENT2_XML = 98
-NCS_NCS_LOAD_TEMPLATE_MISSING_ELEMENT_XML = 29
-NCS_NCS_LOAD_TEMPLATE_MISSING_MACRO_VARS = 117
-NCS_NCS_LOAD_TEMPLATE_MULTIPLE_ELEMENTS_XML = 38
-NCS_NCS_LOAD_TEMPLATE_MULTIPLE_KEY_LEAFS_XML = 77
-NCS_NCS_LOAD_TEMPLATE_MULTIPLE_SP_XML = 35
-NCS_NCS_LOAD_TEMPLATE_SHADOWED_NED_ID_XML = 109
-NCS_NCS_LOAD_TEMPLATE_TAG_AMBIGUOUS_XML = 102
-NCS_NCS_LOAD_TEMPLATE_TRAILING_XML = 32
-NCS_NCS_LOAD_TEMPLATE_UNCLOSED_PI = 88
-NCS_NCS_LOAD_TEMPLATE_UNEXPECTED_PI = 89
-NCS_NCS_LOAD_TEMPLATE_UNKNOWN_ATTRIBUTE_XML = 31
-NCS_NCS_LOAD_TEMPLATE_UNKNOWN_ELEMENT2_XML = 97
-NCS_NCS_LOAD_TEMPLATE_UNKNOWN_ELEMENT_XML = 36
-NCS_NCS_LOAD_TEMPLATE_UNKNOWN_MACRO = 116
-NCS_NCS_LOAD_TEMPLATE_UNKNOWN_NED_ID_XML = 99
-NCS_NCS_LOAD_TEMPLATE_UNKNOWN_NS_XML = 37
-NCS_NCS_LOAD_TEMPLATE_UNKNOWN_PI = 85
-NCS_NCS_LOAD_TEMPLATE_UNKNOWN_SP_XML = 34
-NCS_NCS_LOAD_TEMPLATE_UNMATCHED_PI = 87
-NCS_NCS_LOAD_TEMPLATE_UNSUPPORTED_NED_ID_AT_TAG_XML = 101
-NCS_NCS_LOAD_TEMPLATE_UNSUPPORTED_NED_ID_XML = 100
-NCS_NCS_LOAD_TEMPLATE_UNSUPPORTED_NETCONF_YANG_ATTRIBUTES = 126
-NCS_NCS_MISSING_CLUSTER_AUTH = 73
-NCS_NCS_MISSING_VARIABLES = 52
-NCS_NCS_NED_MULTI_ERROR = 76
-NCS_NCS_NO_CAPABILITIES = 64
-NCS_NCS_NO_DIFF = 71
-NCS_NCS_NO_FORWARD_DIFF = 72
-NCS_NCS_NO_NAMESPACE = 65
-NCS_NCS_NO_SP_TEMPLATE = 48
-NCS_NCS_NO_TEMPLATE = 47
-NCS_NCS_NO_TEMPLATE_XML = 23
-NCS_NCS_NO_WRITE_TRANSACTION = 66
-NCS_NCS_OPERATION_LOCKED = 83
-NCS_NCS_PACKAGE_SYNC_MISMATCHED_LOAD_PATH = 123
-NCS_NCS_SERVICE_CONFLICT = 78
-NCS_NCS_TEMPLATE_CONTEXT_NODE_NOEXISTS = 90
-NCS_NCS_TEMPLATE_COPY_TREE_BAD_OP = 94
-NCS_NCS_TEMPLATE_FOREACH = 51
-NCS_NCS_TEMPLATE_FOREACH_XML = 28
-NCS_NCS_TEMPLATE_GUARD_LENGTH = 59
-NCS_NCS_TEMPLATE_GUARD_LENGTH_XML = 44
-NCS_NCS_TEMPLATE_INSERT = 55
-NCS_NCS_TEMPLATE_INSERT_XML = 40
-NCS_NCS_TEMPLATE_LONE_GUARD = 57
-NCS_NCS_TEMPLATE_LONE_GUARD_XML = 42
-NCS_NCS_TEMPLATE_LOOP_PREVENTION = 95
-NCS_NCS_TEMPLATE_MISSING_VALUE = 56
-NCS_NCS_TEMPLATE_MISSING_VALUE_XML = 41
-NCS_NCS_TEMPLATE_MOVE = 60
-NCS_NCS_TEMPLATE_MOVE_XML = 45
-NCS_NCS_TEMPLATE_MULTIPLE_CONTEXT_NODES = 92
-NCS_NCS_TEMPLATE_NOT_CREATED = 80
-NCS_NCS_TEMPLATE_NOT_CREATED_XML = 79
-NCS_NCS_TEMPLATE_ORDERED_LIST = 54
-NCS_NCS_TEMPLATE_ORDERED_LIST_XML = 39
-NCS_NCS_TEMPLATE_ROOT_LEAF_LIST = 93
-NCS_NCS_TEMPLATE_SAVED_CONTEXT_NOEXISTS = 91
-NCS_NCS_TEMPLATE_STR2VAL = 61
-NCS_NCS_TEMPLATE_STR2VAL_XML = 46
-NCS_NCS_TEMPLATE_UNSUPPORTED_NED_ID = 112
-NCS_NCS_TEMPLATE_VALUE_LENGTH = 58
-NCS_NCS_TEMPLATE_VALUE_LENGTH_XML = 43
-NCS_NCS_TEMPLATE_WHEN = 50
-NCS_NCS_TEMPLATE_WHEN_KEY_XML = 27
-NCS_NCS_TEMPLATE_WHEN_XML = 26
-NCS_NCS_XPATH = 53
-NCS_NCS_XPATH_COMPILE = 49
-NCS_NCS_XPATH_COMPILE_XML = 24
-NCS_NCS_XPATH_VARBIND = 63
-NCS_NCS_XPATH_XML = 25
-NCS_NED_EXTERNAL_ERROR = 6
-NCS_NED_INTERNAL_ERROR = 7
-NCS_NED_OFFLINE_UNAVAILABLE = 108
-NCS_NED_OUT_OF_SYNC = 18
-NCS_NONED = 15
-NCS_NO_EXISTS = 2
-NCS_NO_TEMPLATE = 62
-NCS_NO_YANG_MODULES = 16
-NCS_NS_SUPPORT = 13
-NCS_OVERLAPPING_PRESENCE_AND_ABSENCE_ASSERTION_COMPLIANCE_TEMPLATE = 127
-NCS_OVERLAPPING_STRICT_ASSERTION_COMPLIANCE_TEMPLATE = 129
-NCS_PLAN_LOCATION = 120
-NCS_REVDROP = 17
-NCS_RPC_ERROR = 9
-NCS_SERVICE_CREATE = 0
-NCS_SERVICE_DELETE = 2
-NCS_SERVICE_UPDATE = 1
-NCS_SESSION_LIMIT_EXCEEDED = 115
-NCS_SOUTHBOUND_LOCKED = 4
-NCS_UNKNOWN_NED_ID = 105
-NCS_UNKNOWN_NED_IDS_COMPLIANCE_TEMPLATE = 124
-NCS_UNKNOWN_NED_ID_DEVICE_TEMPLATE = 106
-NCS_XML_PARSE = 11
-NCS_YANGLIB_NO_SCHEMA_FOR_RUNNING = 114
-OPERATION_CASE_EXISTS = 13
-PATCH_FLAG_AAA_CHECKED = 8
-PATCH_FLAG_BUFFER_DAMPENED = 2
-PATCH_FLAG_FILTER = 4
-PATCH_FLAG_INCOMPLETE = 1
-WORKER_SOCKET = 1
-```
diff --git a/developer-reference/pyapi/_ncs.error.md b/developer-reference/pyapi/_ncs.error.md
deleted file mode 100644
index c61c337c..00000000
--- a/developer-reference/pyapi/_ncs.error.md
+++ /dev/null
@@ -1,88 +0,0 @@
-# Python _ncs.error Module
-
-This module defines new NCS Python API exception classes.
-
-Instead of checking for CONFD_ERR or CONFD_EOF return codes all Python
-module APIs raises an exception instead.
-
-## Classes
-
-### _class_ **EOF**
-
-This exception will be thrown from an API function that, from a C perspective,
-would result in a CONFD_EOF return value.
-
-Members:
-
-uinfo(...)
- -Method: - -```python -uinfo() -> _ncs.UserInfo -``` - -
-
-
-
-add_note(...)
- -Method: - -Exception.add_note(note) -- -add a note to the exception - -
-
-
-
-args
- - -
-
-
-
-### _class_ **Error**
-
-This exception will be thrown from an API function that, from a C perspective,
-would result in a CONFD_ERR return value.
-
-Available attributes:
-
-* confd_errno -- the underlying error number
-* confd_strerror -- string representation of the confd_errno
-* confd_lasterr -- string with additional textual information
-* strerror -- os error string (available if confd_errno is CONFD_ERR_OS)
-
-Members:
-
-with_traceback(...)
- -Method: - -Exception.with_traceback(tb) -- -set self.__traceback__ to tb and return self. - -
-
-
-
-add_note(...)
- -Method: - -Exception.add_note(note) -- -add a note to the exception - -
-
-
-
-args
- - -
-
-
-
diff --git a/developer-reference/pyapi/_ncs.events.md b/developer-reference/pyapi/_ncs.events.md
deleted file mode 100644
index 2fc74f74..00000000
--- a/developer-reference/pyapi/_ncs.events.md
+++ /dev/null
@@ -1,405 +0,0 @@
-# \_ncs.events Module
-
-Low level module for subscribing to NCS event notifications.
-
-This module is used to connect to NCS and subscribe to certain events generated by NCS. The API to receive events from NCS is a socket based API whereby the application connects to NCS and receives events on a socket. See also the Notifications chapter in the User Guide. The program misc/notifications/confd\_notifications.c in the examples collection illustrates subscription and processing for all these events, and can also be used standalone in a development environment to monitor NCS events.
-
-This documentation should be read together with the [confd\_lib\_events(3)](../../resources/man/confd_lib_events.3.md) man page.
-
-## Functions
-
-### diff\_notification\_done
-
-```python
-diff_notification_done(sock, tctx) -> None
-```
-
-If the received event was NOTIF\_COMMIT\_DIFF it is important that we call this function when we are done reading the transaction diffs over MAAPI. The transaction is hanging until this function gets called. This function also releases memory associated to the transaction in the library.
-
-Keyword arguments:
-
-* sock -- a previously connected notification socket
-* tctx -- a transaction context
-
-### notifications\_connect
-
-```python
-notifications_connect(sock, mask, ip, port, path) -> None
-```
-
-This function creates a notification socket.
-
-Keyword arguments:
-
-* sock -- a Python socket instance
-* mask -- a bitmask of one or several notification type values
-* ip -- the ip address if socket is AF\_INET (optional)
-* port -- the port if socket is AF\_INET (optional)
-* path -- a filename if socket is AF\_UNIX (optional).
-
-### notifications\_connect2
-
-```python
-notifications_connect2(sock, mask, data, ip, port, path) -> None
-```
-
-This variant of notifications\_connect is required if we wish to subscribe to NOTIF\_HEARTBEAT, NOTIF\_HEALTH\_CHECK, or NOTIF\_STREAM\_EVENT events.
-
-Keyword arguments:
-
-* sock -- a Python socket instance
-* mask -- a bitmask of one or several notification type values
-* data -- a \_events.NotificationsData instance
-* ip -- the ip address if socket is AF\_INET (optional)
-* port -- the port if socket is AF\_INET (optional)
-* path -- a filename if socket is AF\_UNIX (optional)
-
-### read\_notification
-
-```python
-read_notification(sock) -> dict
-```
-
-The application is responsible for polling the notification socket. Once data is available to be read on the socket the application must call read\_notification() to read the data from the socket. On success a dictionary containing notification information will be returned (see below).
-
-Keyword arguments:
-
-* sock -- a previously connected notification socket
-
-On success the returned dict will contain information corresponding to the c struct confd\_notification. The notification type is accessible through the 'type' key. The remaining information will be different depending on which type of notification this is (described below).
-
-Keys for type NOTIF\_AUDIT (struct confd\_audit\_notification):
-
-* logno
-* user
-* msg
-* usid
-
-Keys for type NOTIF\_DAEMON, NOTIF\_NETCONF, NOTIF\_DEVEL, NOTIF\_JSONRPC, NOTIF\_WEBUI, or NOTIF\_TAKEOVER\_SYSLOG (struct confd\_syslog\_notification):
-
-* prio
-* logno
-* msg
-
-Keys for type NOTIF\_COMMIT\_SIMPLE (struct confd\_commit\_notification):
-
-* database
-* diff\_available
-* flags
-* uinfo
-
-Keys for type NOTIF\_COMMIT\_DIFF (struct confd\_commit\_diff\_notification):
-
-* database
-* flags
-* uinfo
-* tctx
-* label (optional)
-* comment (optional)
-
-Keys for type NOTIF\_USER\_SESSION (struct confd\_user\_sess\_notification):
-
-* type
-* uinfo
-* database
-
-Keys for type NOTIF\_HA\_INFO (struct confd\_ha\_notification):
-
-* type (1)
-* noprimary - if (1) is HA\_INFO\_NOPRIMARY
-* secondary\_died - if (1) is HA\_INFO\_SECONDARY\_DIED (see below)
-* secondary\_arrived - if (1) is HA\_INFO\_SECONDARY\_ARRIVED (see below)
-* cdb\_initialized\_by\_copy - if (1) is HA\_INFO\_SECONDARY\_INITIALIZED
-* besecondary\_result - if (1) is HA\_INFO\_BESECONDARY\_RESULT
-
-If secondary\_died or secondary\_arrived is present they will in turn contain a dictionary with the following keys:
-
-* nodeid
-* af (1)
-* ip4 - if (1) is AF\_INET
-* ip6 - if (1) is AF\_INET6
-* str - if (1) if AF\_UNSPEC
-
-Keys for type NOTIF\_SUBAGENT\_INFO (struct confd\_subagent\_notification):
-
-* type
-* name
-
-Keys for type NOTIF\_COMMIT\_FAILED (struct confd\_commit\_failed\_notification):
-
-* provider (1)
-* dbname
-* port - if (1) is DP\_NETCONF
-* af (2) - if (1) is DP\_NETCONF
-* ip4 - if (2) is AF\_INET
-* ip6 - if (2) is AF\_INET6
-* daemon\_name - if (1) is DP\_EXTERNAL
-
-Keys for type NOTIF\_SNMPA (struct confd\_snmpa\_notification):
-
-* pdu\_type (1)
-* request\_id
-* error\_status
-* error\_index
-* port
-* af (2)
-* ip4 - if (3) is AF\_INET
-* ip6 - if (3) is AF\_INET6
-* vb (optional)
-* generic\_trap - if (1) is SNMPA\_PDU\_V1TRAP
-* specific\_trap - if (1) is SNMPA\_PDU\_V1TRAP
-* time\_stamp - if (1) is SNMPA\_PDU\_V1TRAP
-* enterprise - if (1) is SNMPA\_PDU\_V1TRAP (optional)
-
-Keys for type NOTIF\_FORWARD\_INFO (struct confd\_forward\_notification):
-
-* type
-* target
-* uinfo
-
-Keys for type NOTIF\_CONFIRMED\_COMMIT (struct confd\_confirmed\_commit\_notification):
-
-* type
-* timeout
-* uinfo
-
-Keys for type NOTIF\_UPGRADE\_EVENT (struct confd\_upgrade\_notification):
-
-* event
-
-Keys for type NOTIF\_COMPACTION (struct confd\_compaction\_notification):
-
-* dbfile (1) - name of the compacted file
-* type - automatic or manual
-* fsize\_start - size at start (bytes)
-* fsize\_end - size at end (bytes)
-* fsize\_last - size at end of last compaction (bytes)
-* time\_start - start time (microseconds)
-* duration - duration (microseconds)
-* ntrans - number of transactions written to (1) since last compaction
-
-Keys for type NOTIF\_COMMIT\_PROGRESS and NOTIF\_PROGRESS (struct confd\_progress\_notification):
-
-* type (1)
-* timestamp
-* duration if (1) is CONFD\_PROGRESS\_STOP
-* trace\_id (optional)
-* span\_id
-* parent\_span\_id (optional)
-* usid
-* tid
-* datastore
-* context (optional)
-* subsystem (optional)
-* msg (optional)
-* annotation (optional)
-* num\_attributes
-* attributes (optional)
-* num\_links
-* links (optional)
-
-Keys for type NOTIF\_STREAM\_EVENT (struct confd\_stream\_notification):
-
-* type (1)
-* error - if (1) is STREAM\_REPLAY\_FAILED
-* event\_time - if (1) is STREAM\_NOTIFICATION\_EVENT
-* values - if (1) is STREAM\_NOTIFICATION\_EVENT
-
-Keys for type NOTIF\_CQ\_PROGRESS (struct ncs\_cq\_progress\_notification):
-
-* type
-* timestamp
-* cq\_id
-* cq\_tag
-* label
-* completed\_devices (optional)
-* transient\_devices (optional)
-* failed\_devices (optional)
-* failed\_reasons - if failed\_devices is present
-* completed\_services (optional)
-* completed\_services\_completed\_devices - if completed\_services is present
-* failed\_services (optional)
-* failed\_services\_completed\_devices - if failed\_services is present
-* failed\_services\_failed\_devices - if failed\_services is present
-
-Keys for type NOTIF\_CALL\_HOME\_INFO (struct ncs\_call\_home\_notification):
-
-* type (1)
-* device - if (1) is CALL\_HOME\_DEVICE\_CONNECTED or CALL\_HOME\_DEVICE\_DISCONNECTED
-* af (2)
-* ip4 - if (2) is AF\_INET
-* ip6 - if (2) is AF\_INET6
-* port
-* ssh\_host\_key
-* ssh\_key\_alg
-
-### sync\_audit\_network\_notification
-
-```python
-sync_audit_network_notification(sock, usid) -> None
-```
-
-If the received event was NOTIF\_AUDIT\_NETWORK, and we are subscribing to notifications with the flag NOTIF\_AUDIT\_NETWORK\_SYNC, this function must be called when we are done processing the notification. The user session is hanging until this function gets called.
-
-Keyword arguments:
-
-* sock -- a previously connected notification socket
-* usid -- the user session id
-
-### sync\_audit\_notification
-
-```python
-sync_audit_notification(sock, usid) -> None
-```
-
-If the received event was NOTIF\_AUDIT, and we are subscribing to notifications with the flag NOTIF\_AUDIT\_SYNC, this function must be called when we are done processing the notification. The user session is hanging until this function gets called.
-
-Keyword arguments:
-
-* sock -- a previously connected notification socket
-* usid -- the user session id
-
-### sync\_ha\_notification
-
-```python
-sync_ha_notification(sock) -> None
-```
-
-If the received event was NOTIF\_HA\_INFO, and we are subscribing to notifications with the flag NOTIF\_HA\_INFO\_SYNC, this function must be called when we are done processing the notification. All HA processing is blocked until this function gets called.
-
-Keyword arguments:
-
-* sock -- a previously connected notification socket
-
-## Classes
-
-### _class_ **Notification**
-
-This is a placeholder for the c-type struct confd\_notification.
-
-Notification cannot be directly instantiated from Python.
-
-Members:
-
-_None_
-
-### _class_ **NotificationsData**
-
-This type represents the c-type struct confd\_notifications\_data.
-
-The contructor for this type has the following signature:
-
-NotificationsData(hearbeat\_interval, health\_check\_interval, stream\_name, start\_time, stop\_time, xpath\_filter, usid, verbosity) -> object
-
-Keyword arguments:
-
-* heartbeat\_interval -- time in milli seconds (int)
-* health\_check\_interval -- time in milli seconds (int)
-* stream\_name -- name of the notification stream (string)
-* start\_time -- the start time (Value)
-* stop\_time -- the stop time (Value)
-* xpath\_filter -- XPath filter for the stream (string) - optional
-* usid -- user session id for AAA restriction (int) - optional
-* verbosity -- progress verbosity level (int) - optional
-
-Members:
-
-_None_
-
-## Predefined Values
-
-```python
-
-ABORT_COMMIT = 3
-CALL_HOME_DEVICE_CONNECTED = 1
-CALL_HOME_DEVICE_DISCONNECTED = 3
-CALL_HOME_UNKNOWN_DEVICE = 2
-COMPACTION_AUTOMATIC = 1
-COMPACTION_A_CDB = 1
-COMPACTION_MANUAL = 2
-COMPACTION_O_CDB = 2
-COMPACTION_S_CDB = 3
-CONFIRMED_COMMIT = 1
-CONFIRMING_COMMIT = 2
-DP_CDB = 1
-DP_EXTERNAL = 3
-DP_JAVASCRIPT = 5
-DP_NETCONF = 2
-DP_SNMPGW = 4
-FORWARD_INFO_DOWN = 2
-FORWARD_INFO_FAILED = 3
-FORWARD_INFO_UP = 1
-HA_INFO_BESECONDARY_RESULT = 7
-HA_INFO_BESLAVE_RESULT = 7
-HA_INFO_IS_MASTER = 5
-HA_INFO_IS_NONE = 6
-HA_INFO_IS_PRIMARY = 5
-HA_INFO_NOMASTER = 1
-HA_INFO_NOPRIMARY = 1
-HA_INFO_SECONDARY_ARRIVED = 3
-HA_INFO_SECONDARY_DIED = 2
-HA_INFO_SECONDARY_INITIALIZED = 4
-HA_INFO_SLAVE_ARRIVED = 3
-HA_INFO_SLAVE_DIED = 2
-HA_INFO_SLAVE_INITIALIZED = 4
-NCS_CQ_ITEM_COMPLETED = 4
-NCS_CQ_ITEM_DELETED = 6
-NCS_CQ_ITEM_EXECUTING = 2
-NCS_CQ_ITEM_FAILED = 5
-NCS_CQ_ITEM_LOCKED = 3
-NCS_CQ_ITEM_WAITING = 1
-NCS_NOTIF_AUDIT_NETWORK = 268435456
-NCS_NOTIF_AUDIT_NETWORK_SYNC = 536870912
-NCS_NOTIF_CALL_HOME_INFO = 33554432
-NCS_NOTIF_CQ_PROGRESS = 4194304
-NCS_NOTIF_PACKAGE_RELOAD = 2097152
-NOTIF_AUDIT = 1
-NOTIF_AUDIT_SYNC = 131072
-NOTIF_COMMIT_DIFF = 16
-NOTIF_COMMIT_FAILED = 256
-NOTIF_COMMIT_FLAG_CONFIRMED = 1
-NOTIF_COMMIT_FLAG_CONFIRMED_EXTENDED = 2
-NOTIF_COMMIT_PROGRESS = 65536
-NOTIF_COMMIT_SIMPLE = 8
-NOTIF_COMPACTION = 1073741824
-NOTIF_CONFIRMED_COMMIT = 16384
-NOTIF_DAEMON = 2
-NOTIF_DEVEL = 4096
-NOTIF_FORWARD_INFO = 1024
-NOTIF_HA_INFO = 64
-NOTIF_HA_INFO_SYNC = 1048576
-NOTIF_HEALTH_CHECK = 262144
-NOTIF_HEARTBEAT = 8192
-NOTIF_JSONRPC = 67108864
-NOTIF_NETCONF = 2048
-NOTIF_PROGRESS = 16777216
-NOTIF_REOPEN_LOGS = 8388608
-NOTIF_SNMPA = 512
-NOTIF_STREAM_EVENT = 524288
-NOTIF_SUBAGENT_INFO = 128
-NOTIF_SYSLOG = 2
-NOTIF_SYSLOG_TAKEOVER = 6
-NOTIF_TAKEOVER_SYSLOG = 4
-NOTIF_UPGRADE_EVENT = 32768
-NOTIF_USER_SESSION = 32
-NOTIF_WEBUI = 134217728
-PROGRESS_ATTRIBUTE_NUMBER = 2
-PROGRESS_ATTRIBUTE_STRING = 1
-STREAM_NOTIFICATION_COMPLETE = 2
-STREAM_NOTIFICATION_EVENT = 1
-STREAM_REPLAY_COMPLETE = 3
-STREAM_REPLAY_FAILED = 4
-SUBAGENT_INFO_DOWN = 2
-SUBAGENT_INFO_UP = 1
-UPGRADE_ABORTED = 5
-UPGRADE_COMMITED = 4
-UPGRADE_INIT_STARTED = 1
-UPGRADE_INIT_SUCCEEDED = 2
-UPGRADE_PERFORMED = 3
-USER_SESS_LOCK = 3
-USER_SESS_START = 1
-USER_SESS_START_TRANS = 5
-USER_SESS_STOP = 2
-USER_SESS_STOP_TRANS = 6
-USER_SESS_UNLOCK = 4
-```
diff --git a/developer-reference/pyapi/_ncs.ha.md b/developer-reference/pyapi/_ncs.ha.md
deleted file mode 100644
index aede552b..00000000
--- a/developer-reference/pyapi/_ncs.ha.md
+++ /dev/null
@@ -1,142 +0,0 @@
-# \_ncs.ha Module
-
-Low level module for connecting to NCS HA subsystem.
-
-This module is used to connect to the NCS High Availability (HA) subsystem. NCS can replicate the configuration data on several nodes in a cluster. The purpose of this API is to manage the HA functionality. The details on usage of the HA API are described in the chapter High availability in the User Guide.
-
-This documentation should be read together with the [confd\_lib\_ha(3)](../../resources/man/confd_lib_ha.3.md) man page.
-
-## Functions
-
-### bemaster
-
-```python
-bemaster(sock, mynodeid) -> None
-```
-
-This function is deprecated and will be removed. Use beprimary() instead.
-
-### benone
-
-```python
-benone(sock) -> None
-```
-
-Instruct a node to resume the initial state, i.e. neither become primary nor secondary.
-
-Keyword arguments:
-
-* sock -- a previously connected HA socket
-
-### beprimary
-
-```python
-beprimary(sock, mynodeid) -> None
-```
-
-Instruct a HA node to be primary and also give the node a name.
-
-Keyword arguments:
-
-* sock -- a previously connected HA socket
-* mynodeid -- name of the node (Value or string)
-
-### berelay
-
-```python
-berelay(sock) -> None
-```
-
-Instruct an established HA secondary node to be a relay for other secondary nodes.
-
-Keyword arguments:
-
-* sock -- a previously connected HA socket
-
-### besecondary
-
-```python
-besecondary(sock, mynodeid, primary_id, primary_ip, waitreply) -> None
-```
-
-Instruct a NCS HA node to be a secondary node with a named primary node. If waitreply is True the function is synchronous and it will hang until the node has initialized its CDB database. This may mean that the CDB database is copied in its entirety from the primary node. If False, we do not wait for the reply, but it is possible to use a notifications socket and get notified asynchronously via a HA\_INFO\_BESECONDARY\_RESULT notification. In both cases, it is also possible to use a notifications socket and get notified asynchronously when CDB at the secondary node is initialized.
-
-Keyword arguments:
-
-* sock -- a previously connected HA socket
-* mynodeid -- name of this secondary node (Value or string)
-* primary\_id -- name of the primary node (Value or string)
-* primary\_ip -- ip address of the primary node
-* waitreply -- synchronous or not (bool)
-
-### beslave
-
-```python
-beslave(sock, mynodeid, primary_id, primary_ip, waitreply) -> None
-```
-
-This function is deprecated and will be removed. Use besecondary() instead.
-
-### connect
-
-```python
-connect(sock, token, ip, port, pstr) -> None
-```
-
-Connect a HA socket which can be used to control a NCS HA node. The token is a secret string that must be shared by all participants in the cluster. There can only be one HA socket towards NCS. A new call to ha\_connect() makes NCS close the previous connection and reset the token to the new value.
-
-Keyword arguments:
-
-* sock -- a Python socket instance
-* token -- secret string
-* ip -- the ip address if socket is AF\_INET or AF\_INET6 (optional)
-* port -- the port if socket is AF\_INET or AF\_INET6 (optional)
-* pstr -- a filename if socket is AF\_UNIX (optional).
-
-### secondary\_dead
-
-```python
-secondary_dead(sock, nodeid) -> None
-```
-
-This function must be used by the application to inform NCS HA subsystem that another node which is possibly connected to NCS is dead.
-
-Keyword arguments:
-
-* sock -- a previously connected HA socket
-* nodeid -- name of the node (Value or string)
-
-### slave\_dead
-
-```python
-slave_dead(sock, nodeid) -> None
-```
-
-This function is deprecated and will be removed. Use secondary\_dead() instead.
-
-### status
-
-```python
-status(sock) -> None
-```
-
-Query a ConfD HA node for its status.
-
-Returns a 2-tuple of the HA status of the node in the format (State,\[list\_of\_nodes]) where 'list\_of\_nodes' is the primary/secondary(s) connected with node.
-
-Keyword arguments:
-
-* sock -- a previously connected HA socket
-
-## Predefined Values
-
-```python
-
-STATE_MASTER = 3
-STATE_NONE = 1
-STATE_PRIMARY = 3
-STATE_SECONDARY = 2
-STATE_SECONDARY_RELAY = 4
-STATE_SLAVE = 2
-STATE_SLAVE_RELAY = 4
-```
diff --git a/developer-reference/pyapi/_ncs.maapi.md b/developer-reference/pyapi/_ncs.maapi.md
deleted file mode 100644
index 96264589..00000000
--- a/developer-reference/pyapi/_ncs.maapi.md
+++ /dev/null
@@ -1,3005 +0,0 @@
-# \_ncs.maapi Module
-
-Low level module for connecting to NCS with a read/write interface inside transactions.
-
-This module is used to connect to the NCS transaction manager. The API described here has several purposes. We can use MAAPI when we wish to implement our own proprietary management agent. We also use MAAPI to attach to already existing NCS transactions, for example when we wish to implement semantic validation of configuration data in Python, and also when we wish to implement CLI wizards in Python.
-
-This documentation should be read together with the [confd\_lib\_maapi(3)](../../resources/man/confd_lib_maapi.3.md) man page.
-
-## Functions
-
-### aaa\_reload
-
-```python
-aaa_reload(sock, synchronous) -> None
-```
-
-Start a reload of aaa from external data provider.
-
-Used by external data provider to notify that there is a change to the AAA data. Calling the function with the argument 'synchronous' set to 1 or True means that the call will block until the loading is completed.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* synchronous -- if 1, will wait for the loading complete and return when the loading is complete; if 0, will only initiate the loading of AAA data and return immediately
-
-### aaa\_reload\_path
-
-```python
-aaa_reload_path(sock, synchronous, path) -> None
-```
-
-Start a reload of aaa from external data provider.
-
-A variant of \_maapi\_aaa\_reload() that causes only the AAA subtree given by path to be loaded.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* synchronous -- if 1, will wait for the loading complete and return when the loading is complete; if 0, will only initiate the loading of AAA data and return immediately
-* path -- the subtree to be loaded
-
-### abort\_trans
-
-```python
-abort_trans(sock, thandle) -> None
-```
-
-Final phase of a two phase transaction, aborting the trans.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-
-### abort\_upgrade
-
-```python
-abort_upgrade(sock) -> None
-```
-
-Can be called before committing upgrade in order to abort it.
-
-Final step in an upgrade.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### apply\_template
-
-```python
-apply_template(sock, thandle, template, variables, flags, rootpath) -> None
-```
-
-Apply a template that has been loaded into NCS. The template parameter gives the name of the template. This is NOT a FASTMAP function, for that use shared\_ncs\_apply\_template instead.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* template -- template name
-* variables -- None or a list of variables in the form of tuples
-* flags -- should be 0
-* rootpath -- in what context to apply the template
-
-### apply\_trans
-
-```python
-apply_trans(sock, thandle, keepopen) -> None
-```
-
-Apply a transaction.
-
-Validates, prepares and eventually commits or aborts the transaction. If the validation fails and the 'keep\_open' argument is set to 1 or True, the transaction is left open and the developer can react upon the validation errors.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* keepopen -- if true, transaction is not discarded if validation fails
-
-### apply\_trans\_flags
-
-```python
-apply_trans_flags(sock, thandle, keepopen, flags) -> None
-```
-
-A variant of apply\_trans() that takes an additional 'flags' argument.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* keepopen -- if true, transaction is not discarded if validation fails
-* flags -- flags to set in the transaction
-
-### apply\_trans\_params
-
-```python
-apply_trans_params(sock, thandle, keepopen, params) -> list
-```
-
-A variant of apply\_trans() that takes commit parameters in form of a list ofTagValue objects and returns a list of TagValue objects depending on theparameters passed in.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* keepopen -- if true, transaction is not discarded if validation fails
-* params -- list of TagValue objects
-
-### attach
-
-```python
-attach(sock, hashed_ns, ctx) -> None
-```
-
-Attach to a existing transaction.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* hashed\_ns -- the namespace to use
-* ctx -- transaction context
-
-### attach2
-
-```python
-attach2(sock, hashed_ns, usid, thandle) -> None
-```
-
-Used when there is no transaction context beforehand, to attach to a existing transaction.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* hashed\_ns -- the namespace to use
-* usid -- user session id, can be set to 0 to use the owner of the transaction
-* thandle -- transaction handle
-
-### attach\_init
-
-```python
-attach_init(sock) -> int
-```
-
-Attach the \_MAAPI socket to the special transaction available during phase0. Returns the thandle as an integer.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### authenticate
-
-```python
-authenticate(sock, user, password, n) -> tuple
-```
-
-Authenticate a user session. Use the 'n' to get a list of n-1 groups that the user is a member of. Use n=1 if the function is used in a context where the group names are not needed. Returns 1 if accepted without groups. If the authentication failed or was accepted a tuple with first element status code, 0 for rejection and 1 for accepted is returned. The second element either contains the reason for the rejection as a string OR a list groupnames.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* user -- username
-* pass -- password
-* n -- number of groups to return
-
-### authenticate2
-
-```python
-authenticate2(sock, user, password, src_addr, src_port, context, prot, n) -> tuple
-```
-
-This function does the same thing as maapi.authenticate(), but allows for passing of the additional parameters src\_addr, src\_port, context, and prot, which otherwise are passed only to maapi\_start\_user\_session()/ maapi\_start\_user\_session2(). The parameters are passed on to an external authentication executable. Keyword arguments:
-
-* sock -- a python socket instance
-* user -- username
-* pass -- password
-* src\_addr -- ip address
-* src\_port -- port number
-* context -- context for the session
-* prot -- the protocol used by the client for connecting
-* n -- number of groups to return
-
-### candidate\_abort\_commit
-
-```python
-candidate_abort_commit(sock) -> None
-```
-
-Cancel an ongoing confirmed commit.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### candidate\_abort\_commit\_persistent
-
-```python
-candidate_abort_commit_persistent(sock, persist_id) -> None
-```
-
-Cancel an ongoing confirmed commit with the cookie given by persist\_id.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* persist\_id -- gives the cookie for an already ongoing persistent confirmed commit
-
-### candidate\_commit
-
-```python
-candidate_commit(sock) -> None
-```
-
-This function copies the candidate to running.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### candidate\_commit\_info
-
-```python
-candidate_commit_info(sock, persist_id, label, comment) -> None
-```
-
-Commit the candidate to running, or confirm an ongoing confirmed commit, and set the Label and/or Comment that is stored in the rollback file when the candidate is committed to running.
-
-Note:
-
-> To ensure the Label and/or Comment are stored in the rollback file in all cases when doing a confirmed commit, they must be given with both, the confirmed commit (using maapi\_candidate\_confirmed\_commit\_info()) and the confirming commit (using this function).
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* persist\_id -- gives the cookie for an already ongoing persistent confirmed commit
-* label -- the Label
-* comment -- the Comment
-
-### candidate\_commit\_persistent
-
-```python
-candidate_commit_persistent(sock, persist_id) -> None
-```
-
-Confirm an ongoing persistent commit with the cookie given by persist\_id.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* persist\_id -- gives the cookie for an already ongoing persistent confirmed commit
-
-### candidate\_confirmed\_commit
-
-```python
-candidate_confirmed_commit(sock, timeoutsecs) -> None
-```
-
-This function also copies the candidate into running. However if a call to maapi\_candidate\_commit() is not done within timeoutsecs an automatic rollback will occur.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* timeoutsecs -- timeout in seconds
-
-### candidate\_confirmed\_commit\_info
-
-```python
-candidate_confirmed_commit_info(sock, timeoutsecs, persist, persist_id, label, comment) -> None
-```
-
-Like candidate\_confirmed\_commit\_persistent, but also allows for setting the Label and/or Comment that is stored in the rollback file when the candidate is committed to running.
-
-Note:
-
-> To ensure the Label and/or Comment are stored in the rollback file in all cases when doing a confirmed commit, they must be given with both, the confirmed commit (using this function) and the confirming commit (using candidate\_commit\_info()).
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* timeoutsecs -- timeout in seconds
-* persist -- sets the cookie for the persistent confirmed commit
-* persist\_id -- gives the cookie for an already ongoing persistent confirmed commit
-* label -- the Label
-* comment -- the Comment
-
-### candidate\_confirmed\_commit\_persistent
-
-```python
-candidate_confirmed_commit_persistent(sock, timeoutsecs, persist, persist_id) -> None
-```
-
-Start or extend a confirmed commit using persist id.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* timeoutsecs -- timeout in seconds
-* persist -- sets the cookie for the persistent confirmed commit
-* persist\_id -- gives the cookie for an already ongoing persistent confirmed commit
-
-### candidate\_reset
-
-```python
-candidate_reset(sock) -> None
-```
-
-Copy running into candidate.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### candidate\_validate
-
-```python
-candidate_validate(sock) -> None
-```
-
-This function validates the candidate.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### cd
-
-```python
-cd(sock, thandle, path) -> None
-```
-
-Change current position in the tree.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* path -- position to change to
-
-### clear\_opcache
-
-```python
-clear_opcache(sock, path) -> None
-```
-
-Clearing of operational data cache.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* path -- the path to the subtree to clear
-
-### cli\_accounting
-
-```python
-cli_accounting(sock, user, usid, cmdstr) -> None
-```
-
-Generates an audit log entry in the CLI audit log.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* user -- user to generate the entry for
-* thandle -- transaction handle
-
-### cli\_cmd
-
-```python
-cli_cmd(sock, usess, buf) -> None
-```
-
-Execute CLI command in the ongoing CLI session.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* usess -- user session
-* buf -- string to write
-
-### cli\_cmd2
-
-```python
-cli_cmd2(sock, usess, buf, flags) -> None
-```
-
-Execute CLI command in a ongoing CLI session. With flags: CMD\_NO\_FULLPATH - Do not perform the fullpath check on show commands. CMD\_NO\_HIDDEN - Allows execution of hidden CLI commands.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* usess -- user session
-* buf -- string to write
-* flags -- as above
-
-### cli\_cmd3
-
-```python
-cli_cmd3(sock, usess, buf, flags, unhide) -> None
-```
-
-Execute CLI command in a ongoing CLI session.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* usess -- user session
-* buf -- string to write
-* flags -- as above
-* unhide -- The unhide parameter is used for passing a hide group which is unhidden during the execution of the command.
-
-### cli\_cmd4
-
-```python
-cli_cmd4(sock, usess, buf, flags, unhide) -> None
-```
-
-Execute CLI command in a ongoing CLI session.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* usess -- user session
-* buf -- string to write
-* flags -- as above
-* unhide -- The unhide parameter is used for passing a hide group which is unhidden during the execution of the command.
-
-### cli\_cmd\_to\_path
-
-```python
-cli_cmd_to_path(sock, line, nsize, psize) -> tuple
-```
-
-Returns string of the C/I namespaced CLI path that can be associated with the given command. Returns a tuple ns and path.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* line -- data model path as string
-* nsize -- limit length of namespace
-* psize -- limit length of path
-
-### cli\_cmd\_to\_path2
-
-```python
-cli_cmd_to_path2(sock, thandle, line, nsize, psize) -> tuple
-```
-
-Returns string of the C/I namespaced CLI path that can be associated with the given command. In the context of the provided transaction handle. Returns a tuple ns and path.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* line -- data model path as string
-* nsize -- limit length of namespace
-* psize -- limit length of path
-
-### cli\_diff\_cmd
-
-```python
-cli_diff_cmd(sock, thandle, thandle_old, flags, path, size) -> str
-```
-
-Get the diff between two sessions as a series C/I cli commands. Returns a string. If no changes exist between the two sessions for the given path a \_ncs.error.Error will be thrown with the error set to ERR\_BADPATH
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* thandle\_old -- transaction handle
-* flags -- as for cli\_path\_cmd
-* path -- as for cli\_path\_cmd
-* size -- limit diff
-
-### cli\_get
-
-```python
-cli_get(sock, usess, opt, size) -> str
-```
-
-Read CLI session parameter or attribute.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* usess -- user session
-* opt -- option to get
-* size -- maximum response size (optional, default 1024)
-
-### cli\_path\_cmd
-
-```python
-cli_path_cmd(sock, thandle, flags, path, size) -> str
-```
-
-Returns string of the C/I CLI command that can be associated with the given path. The flags can be given as FLAG\_EMIT\_PARENTS to enable the commands to reach the submode for the path to be emitted. The flags can be given as FLAG\_DELETE to emit the command to delete the given path. The flags can be given as FLAG\_NON\_RECURSIVE to prevent that all children to a container or list item are displayed.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* flags -- as above
-* path -- the path for the cmd
-* size -- limit cmd
-
-### cli\_prompt
-
-```python
-cli_prompt(sock, usess, prompt, echo, size) -> str
-```
-
-Prompt user for a string.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* usess -- user session
-* prompt -- string to show the user
-* echo -- determines wether to control if the input should be echoed or not. ECHO shows the input, NOECHO does not
-* size -- maximum response size (optional, default 1024)
-
-### cli\_set
-
-```python
-cli_set(sock, usess, opt, value) -> None
-```
-
-Set CLI session parameter.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* usess -- user session
-* opt -- option to set
-* value -- the new value of the session parameter
-
-### cli\_write
-
-```python
-cli_write(sock, usess, buf) -> None
-```
-
-Write to the cli.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* usess -- user session
-* buf -- string to write
-
-### close
-
-```python
-close(sock) -> None
-```
-
-Ends session and closes socket.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### commit\_trans
-
-```python
-commit_trans(sock, thandle) -> None
-```
-
-Final phase of a two phase transaction, committing the trans.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-
-### commit\_upgrade
-
-```python
-commit_upgrade(sock) -> None
-```
-
-Final step in an upgrade.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### confirmed\_commit\_in\_progress
-
-```python
-confirmed_commit_in_progress(sock) -> int
-```
-
-Checks whether a confirmed commit is ongoing. Returns a positive integer being the usid of confirmed commit operation in progress or 0 if no confirmed commit is in progress.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### connect
-
-```python
-connect(sock, ip, port, path) -> None
-```
-
-Connect to the system daemon.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* ip -- the ip address
-* port -- the port
-* path -- the path if socket is AF\_UNIX (optional)
-
-### copy
-
-```python
-copy(sock, from_thandle, to_thandle) -> None
-```
-
-Copy all data from one data store to another.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* from\_thandle -- transaction handle
-* to\_thandle -- transaction handle
-
-### copy\_path
-
-```python
-copy_path(sock, from_thandle, to_thandle, path) -> None
-```
-
-Copy subtree rooted at path from one data store to another.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* from\_thandle -- transaction handle
-* to\_thandle -- transaction handle
-* path -- the subtree rooted at path is copied
-
-### copy\_running\_to\_startup
-
-```python
-copy_running_to_startup(sock) -> None
-```
-
-Copies running to startup.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### copy\_tree
-
-```python
-copy_tree(sock, thandle, frompath, topath) -> None
-```
-
-Copy subtree rooted at frompath to topath.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* frompath -- the subtree rooted at path is copied
-* topath -- to which path the subtree is copied
-
-### create
-
-```python
-create(sock, thandle, path) -> None
-```
-
-Create a new list entry, a presence container or a leaf of type empty (unless in a union, if type empty is in a union use set\_elem instead) in the data tree.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* path -- path of item to create
-
-### cs\_node\_cd
-
-```python
-cs_node_cd(socket, thandle, path) -> Union[_ncs.CsNode, None]
-```
-
-Utility function which finds the resulting CsNode given a string keypath.
-
-Does the same thing as \_ncs.cs\_node\_cd(), but can handle paths that are ambiguous due to traversing a mount point, by sending a request to the daemon
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* path -- the keypath
-
-### cs\_node\_children
-
-```python
-cs_node_children(sock, thandle, mount_point, path) -> List[_ncs.CsNode]
-```
-
-Retrieve a list of the children nodes of the node given by mount\_point that are valid for path. The mount\_point node must be a mount point (i.e. mount\_point.is\_mount\_point() == True), and the path must lead to a specific instance of this node (including the final keys if mount\_point is a list node). The thandle parameter is optional, i.e. it can be given as -1 if a transaction is not available.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* mount\_point -- a CsNode instance
-* path -- the path to the instance of the node
-
-### delete
-
-```python
-delete(sock, thandle, path) -> None
-```
-
-Delete an existing list entry, a presence container or a leaf of type empty from the data tree.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* path -- path of item to delete
-
-### delete\_all
-
-```python
-delete_all(sock, thandle, how) -> None
-```
-
-Delete all data within a transaction.
-
-The how argument specifies how to delete: DEL\_SAFE - Delete everything except namespaces that were exported with tailf:export none. Top-level nodes that cannot be deleted due to AAA rules are left in place (descendant nodes may be deleted if the rules allow it). DEL\_EXPORTED - As DEL\_SAFE, but AAA rules are ignored. DEL\_ALL - Delete everything, AAA rules are ignored.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* how -- DEL\_SAFE, DEL\_EXPORTED or DEL\_ALL
-
-### delete\_config
-
-```python
-delete_config(sock, name) -> None
-```
-
-Empties a datastore.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* name -- name of the datastore to empty
-
-### destroy\_cursor
-
-```python
-destroy_cursor(mc) -> None
-```
-
-Deallocates memory which is associated with the cursor.
-
-Keyword arguments:
-
-* mc -- maapiCursor
-
-### detach
-
-```python
-detach(sock, ctx) -> None
-```
-
-Detaches an attached \_MAAPI socket.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* ctx -- transaction context
-
-### detach2
-
-```python
-detach2(sock, thandle) -> None
-```
-
-Detaches an attached \_MAAPI socket when we do not have a transaction context available.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-
-### diff\_iterate
-
-```python
-diff_iterate(sock, thandle, iter, flags) -> None
-```
-
-Iterate through a transaction diff.
-
-For each diff in the transaction the callback function 'iter' will be called. The iter function needs to have the following signature:
-
-```
-def iter(keypath, operation, oldvalue, newvalue)
-```
-
-Where arguments are:
-
-* keypath - the affected path (HKeypathRef)
-* operation - one of MOP\_CREATED, MOP\_DELETED, MOP\_MODIFIED, MOP\_VALUE\_SET, MOP\_MOVED\_AFTER, or MOP\_ATTR\_SET
-* oldvalue - always None
-* newvalue - see below
-
-The 'newvalue' argument may be set for operation MOP\_VALUE\_SET and is a Value object in that case. For MOP\_MOVED\_AFTER it may be set to a list of key values identifying an entry in the list - if it's None the list entry has been moved to the beginning of the list. For MOP\_ATTR\_SET it will be set to a 2-tuple of Value's where the first Value is the attribute set and the second Value is the value the attribute was set to. If the attribute has been deleted the second value is of type C\_NOEXISTS
-
-The iter function should return one of:
-
-* ITER\_STOP - Stop further iteration
-* ITER\_RECURSE - Recurse further down the node children
-* ITER\_CONTINUE - Ignore node children and continue with the node's siblings
-
-One could also define a class implementing the call function as:
-
-```
-class DiffIterator(object):
- def __init__(self):
- self.count = 0
-
- def __call__(self, kp, op, oldv, newv):
- print('kp={0}, op={1}, oldv={2}, newv={3}'.format(
- str(kp), str(op), str(oldv), str(newv)))
- self.count += 1
- return _confd.ITER_RECURSE
-```
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* iter -- iterator function, will be called for every diff in the transaction
-* flags -- bitmask of ITER\_WANT\_ATTR and ITER\_WANT\_P\_CONTAINER
-
-### disconnect\_remote
-
-```python
-disconnect_remote(sock, address) -> None
-```
-
-Disconnect all remote connections to 'address' except HA connections.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* address -- ip address (string)
-
-### disconnect\_sockets
-
-```python
-disconnect_sockets(sock, sockets) -> None
-```
-
-Disconnect 'sockets' which is a list of sockets (fileno).
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* sockets -- list of sockets (int)
-
-### do\_display
-
-```python
-do_display(sock, thandle, path) -> int
-```
-
-If the data model uses the YANG when or tailf:display-when statement, this function can be used to determine if the item given by 'path' should be displayed or not.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* path -- path to the 'display-when' statement
-
-### end\_progress\_span
-
-```python
-end_progress_span(sock, span, annotation) -> int
-```
-
-Ends a progress span started from start\_progress\_span() or start\_progress\_span\_th().
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* span -- span\_id (string) or dict with key 'span\_id'
-* annotation -- metadata about the event, indicating error, explains latency or shows result etc
-
-### end\_user\_session
-
-```python
-end_user_session(sock) -> None
-```
-
-End the MAAPI user session associated with the socket
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### exists
-
-```python
-exists(sock, thandle, path) -> bool
-```
-
-Check wether a node in the data tree exists. Returns boolean.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* path -- position to check
-
-### find\_next
-
-```python
-find_next(mc, type, inkeys) -> Union[List[_ncs.Value], bool]
-```
-
-Update the cursor mc with the key(s) for the list entry designated by the type and inkeys parameters. This function may be used to start a traversal from an arbitrary entry in a list. Keys for subsequent entries may be retrieved with the get\_next() function. When no more keys are found, False is returned.
-
-The strategy to use is defined by type:
-
-```
-FIND_NEXT - The keys for the first list entry after the one
- indicated by the inkeys argument.
-FIND_SAME_OR_NEXT - If the values in the inkeys array completely
- identifies an actual existing list entry, the keys for
- this entry are requested. Otherwise the same logic as
- for FIND_NEXT above.
-```
-
-Keyword arguments:
-
-* mc -- maapiCursor
-* type -- CONFD\_FIND\_NEXT or CONFD\_FIND\_SAME\_OR\_NEXT
-* inkeys -- where to start finding
-
-### finish\_trans
-
-```python
-finish_trans(sock, thandle) -> None
-```
-
-Finish a transaction.
-
-If the transaction is implemented by an external database, this will invoke the finish() callback.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-
-### get\_attrs
-
-```python
-get_attrs(sock, thandle, attrs, keypath) -> list
-```
-
-Get attributes for a node. Returns a list of attributes.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* attrs -- list of type of attributes to get
-* keypath -- path to choice
-
-### get\_authorization\_info
-
-```python
-get_authorization_info(sock, usessid) -> _ncs.AuthorizationInfo
-```
-
-This function retrieves authorization info for a user session,i.e. the groups that the user has been assigned to.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* usessid -- user session id
-
-### get\_case
-
-```python
-get_case(sock, thandle, choice, keypath) -> _ncs.Value
-```
-
-Get the case from a YANG choice statement.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* choice -- choice name
-* keypath -- path to choice
-
-### get\_elem
-
-```python
-get_elem(sock, thandle, path) -> _ncs.Value
-```
-
-Path must be a valid leaf node in the data tree. Returns a Value object.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* path -- position of elem
-
-### get\_my\_user\_session\_id
-
-```python
-get_my_user_session_id(sock) -> int
-```
-
-Returns user session id
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### get\_next
-
-```python
-get_next(mc) -> Union[List[_ncs.Value], bool]
-```
-
-Iterates and gets the keys for the next entry in a list. When no more keys are found, False is returned.
-
-Keyword arguments:
-
-* mc -- maapiCursor
-
-### get\_object
-
-```python
-get_object(sock, thandle, n, keypath) -> List[_ncs.Value]
-```
-
-Read at most n values from keypath in a list.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* path -- position of list entry
-
-### get\_objects
-
-```python
-get_objects(mc, n, nobj) -> List[_ncs.Value]
-```
-
-Read at most n values from each nobj lists starting at Cursor mc. Returns a list of Value's.
-
-Keyword arguments:
-
-* mc -- maapiCursor
-* n -- at most n values will be read
-* nobj -- number of nobj lists which n elements will be taken from
-
-### get\_rollback\_id
-
-```python
-get_rollback_id(sock, thandle) -> int
-```
-
-Get rollback id from a committed transaction. Returns int with fixed id, where -1 indicates an error or no rollback id available.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-
-### get\_running\_db\_status
-
-```python
-get_running_db_status(sock) -> int
-```
-
-If a transaction fails in the commit() phase, the configuration database is in in a possibly inconsistent state. This function queries ConfD on the consistency state. Returns 1 if the configuration is consistent and 0 otherwise.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### get\_schema\_file\_path
-
-```python
-get_schema_file_path(sock) -> str
-```
-
-If shared memory schema support has been enabled, this function will return the pathname of the file used for the shared memory mapping, which can then be passed to the mmap\_schemas() function>
-
-If creation of the schema file is in progress when the function is called, the call will block until the creation has completed.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### get\_stream\_progress
-
-```python
-get_stream_progress(sock, id) -> int
-```
-
-Used in conjunction with a maapi stream to see how much data has been consumed.
-
-This function allows us to limit the amount of data 'in flight' between the application and the system. The sock parameter must be the maapi socket used for a function call that required a stream socket for writing (currently the only such function is load\_config\_stream()), and the id parameter is the id returned by that function.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* id -- the id returned from load\_config\_stream()
-
-### get\_templates
-
-```python
-get_templates(sock) -> list
-```
-
-Get the defined templates.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### get\_trans\_params
-
-```python
-get_trans_params(sock, thandle) -> list
-```
-
-Get the commit parameters for a transaction. The commit parameters are returned as a list of TagValue objects.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-
-### get\_user\_session
-
-```python
-get_user_session(sock, usessid) -> _ncs.UserInfo
-```
-
-Return user info.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* usessid -- session id
-
-### get\_user\_session\_identification
-
-```python
-get_user_session_identification(sock, usessid) -> dict
-```
-
-Get user session identification data.
-
-Get the user identification data related to a user session provided by the 'usessid' argument. The function returns a dict with the user identification data.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* usessid -- user session id
-
-### get\_user\_session\_opaque
-
-```python
-get_user_session_opaque(sock, usessid) -> str
-```
-
-Returns a string containing additional 'opaque' information, if additional 'opaque' information is available.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* usessid -- user session id
-
-### get\_user\_sessions
-
-```python
-get_user_sessions(sock) -> list
-```
-
-Return a list of session ids.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### get\_values
-
-```python
-get_values(sock, thandle, values, keypath) -> list
-```
-
-Get values from keypath based on the Tag Value array values.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* values -- list of tagValues
-
-### getcwd
-
-```python
-getcwd(sock, thandle) -> str
-```
-
-Get the current position in the tree as a string.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-
-### getcwd\_kpath
-
-```python
-getcwd_kpath(sock, thandle) -> _ncs.HKeypathRef
-```
-
-Get the current position in the tree as a HKeypathRef.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-
-### hide\_group
-
-```python
-hide_group(sock, thandle, group_name) -> None
-```
-
-Hide all nodes belonging to a hide group in a transaction that started with flag FLAG\_HIDE\_ALL\_HIDEGROUPS.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* group\_name -- the group name
-
-### init\_cursor
-
-```python
-init_cursor(sock, thandle, path) -> maapi.Cursor
-```
-
-Whenever we wish to iterate over the entries in a list in the data tree, we must first initialize a cursor.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* path -- position of elem
-* secondary\_index -- name of secondary index to use (optional)
-* xpath\_expr -- xpath expression used to filter results (optional)
-
-### init\_upgrade
-
-```python
-init_upgrade(sock, timeoutsecs, flags) -> None
-```
-
-First step in an upgrade, initializes the upgrade procedure.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* timeoutsecs -- maximum time to wait for user to voluntarily exit from 'configuration' mode
-* flags -- 0 or 'UPGRADE\_KILL\_ON\_TIMEOUT' (will terminate all ongoing transactions
-
-### insert
-
-```python
-insert(sock, thandle, path) -> None
-```
-
-Insert a new entry in a list, the key of the list must be a integer.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* path -- the subtree rooted at path is copied
-
-### install\_crypto\_keys
-
-```python
-install_crypto_keys(sock) -> None
-```
-
-Copy configured AES keys into the memory in the library.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### is\_candidate\_modified
-
-```python
-is_candidate_modified(sock) -> bool
-```
-
-Checks if candidate is modified.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### is\_lock\_set
-
-```python
-is_lock_set(sock, name) -> int
-```
-
-Check if db name is locked. Return the 'usid' of the user holding the lock or 0 if not locked.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### is\_running\_modified
-
-```python
-is_running_modified(sock) -> bool
-```
-
-Checks if running is modified.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### iterate
-
-```python
-iterate(sock, thandle, iter, flags, path) -> None
-```
-
-Used to iterate over all the data in a transaction and the underlying data store as opposed to only iterate over changes like diff\_iterate.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* iter -- iterator function, will be called for every diff in the transaction
-* flags -- ITER\_WANT\_ATTR or 0
-* path -- receive only changes from this path and below
-
-The iter callback function should have the following signature:
-
-```
-def my_iterator(kp, v, attr_vals)
-```
-
-### keypath\_diff\_iterate
-
-```python
-keypath_diff_iterate(sock, thandle, iter, flags, path) -> None
-```
-
-Like diff\_iterate but takes an additional path argument.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* iter -- iterator function, will be called for every diff in the transaction
-* flags -- bitmask of ITER\_WANT\_ATTR and ITER\_WANT\_P\_CONTAINER
-* path -- receive only changes from this path and below
-
-### kill\_user\_session
-
-```python
-kill_user_session(sock, usessid) -> None
-```
-
-Kill MAAPI user session with session id.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* usessid -- the MAAPI session id to be killed
-
-### load\_config
-
-```python
-load_config(sock, thandle, flags, filename) -> None
-```
-
-Loads configuration from 'filename'. The caller of the function has to indicate which format the file has by using one of the following flags:
-
-```
- CONFIG_XML -- XML format
- CONFIG_J -- Juniper curly bracket style
- CONFIG_C -- Cisco XR style
- CONFIG_TURBO_C -- A faster version of CONFIG_C
- CONFIG_C_IOS -- Cisco IOS style
-```
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- a transaction handle
-* flags -- as above
-* filename -- to read the configuration from
-
-### load\_config\_cmds
-
-```python
-load_config_cmds(sock, thandle, flags, cmds, path) -> None
-```
-
-Loads configuration from the string 'cmds'
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- a transaction handle
-* cmds -- a string of cmds
-* flags -- as above
-
-### load\_config\_stream
-
-```python
-load_config_stream(sock, th, flags) -> int
-```
-
-Loads configuration from the stream socket. The th and flags parameters are the same as for load\_config(). Returns and id.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- a transaction handle
-* flags -- as for load\_config()
-
-### load\_config\_stream\_result
-
-```python
-load_config_stream_result(sock, id) -> int
-```
-
-We use this function to verify that the configuration we wrote on the stream socket was successfully loaded.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* id -- the id returned from load\_config\_stream()
-
-### load\_schemas
-
-```python
-load_schemas(sock) -> None
-```
-
-Loads all schema information into the lib.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### load\_schemas\_list
-
-```python
-load_schemas_list(sock, flags, nshash, nsflags) -> None
-```
-
-Loads selected schema information into the lib.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* flags -- the flags to set
-* nshash -- the listed namespaces that schema information should be loaded for
-* nsflags -- namespace specific flags
-
-### lock
-
-```python
-lock(sock, name) -> None
-```
-
-Lock database with name.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* name -- name of the database to lock
-
-### lock\_partial
-
-```python
-lock_partial(sock, name, xpaths) -> int
-```
-
-Lock a subset (xpaths) of database name. Returns lockid.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* xpaths -- a list of strings
-
-### move
-
-```python
-move(sock, thandle, tokey, path) -> None
-```
-
-Moves an existing list entry, i.e. renames the entry using the tokey parameter.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* tokey -- confdValue list
-* path -- the subtree rooted at path is copied
-
-### move\_ordered
-
-```python
-move_ordered(sock, thandle, where, tokey, path) -> None
-```
-
-Moves an entry in an 'ordered-by user' statement to a new position.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* where -- FIRST, LAST, BEFORE or AFTER
-* tokey -- confdValue list
-* path -- the subtree rooted at path is copied
-
-### netconf\_ssh\_call\_home
-
-```python
-netconf_ssh_call_home(sock, host, port) -> None
-```
-
-Initiates a NETCONF SSH Call Home connection.
-
-Keyword arguments:
-
-sock -- a python socket instance host -- an ipv4 addres, ipv6 address, or host name port -- the port to connect to
-
-### netconf\_ssh\_call\_home\_opaque
-
-```python
-netconf_ssh_call_home_opaque(sock, host, opaque, port) -> None
-```
-
-Initiates a NETCONF SSH Call Home connection.
-
-Keyword arguments: sock -- a python socket instance host -- an ipv4 addres, ipv6 address, or host name opaque -- opaque string passed to an external call home session port -- the port to connect to
-
-### num\_instances
-
-```python
-num_instances(sock, thandle, path) -> int
-```
-
-Return the number of instances in a list in the tree.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* path -- position to check
-
-### perform\_upgrade
-
-```python
-perform_upgrade(sock, loadpathdirs) -> None
-```
-
-Second step in an upgrade. Loads new data model files.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* loadpathdirs -- list of directories that are searched for CDB 'init' files
-
-### popd
-
-```python
-popd(sock, thandle) -> None
-```
-
-Return to earlier saved (pushd) position in the tree.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-
-### prepare\_trans
-
-```python
-prepare_trans(sock, thandle) -> None
-```
-
-First phase of a two-phase trans.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-
-### prepare\_trans\_flags
-
-```python
-prepare_trans_flags(sock, thandle, flags) -> None
-```
-
-First phase of a two-phase trans with flags.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* flags -- flags to set in the transaction
-
-### prio\_message
-
-```python
-prio_message(sock, to, message) -> None
-```
-
-Like sys\_message but will be output directly instead of delivered when the receiver terminates any ongoing command.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* to -- user to send message to or 'all' to send to all users
-* message -- the message
-
-### progress\_info
-
-```python
-progress_info(sock, msg, verbosity, attrs, links, path) -> None
-```
-
-While spans represents a pair of data points: start and stop; info events are instead singular events, one point in time. Call progress\_info() to write a progress span info event to the progress trace. The info event will have the same span-id as the start and stop events of the currently ongoing progress span in the active user session or transaction. See start\_progress\_span() for more information.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* msg -- message to report
-* verbosity -- VERBOSITY\_\*, default: VERBOSITY\_NORMAL (optional)
-* attrs -- user defined attributes (dict)
-* links -- to existing traces or spans \[{'trace\_id':'...', 'span\_id':'...'}]
-* path -- keypath to an action/leaf/service
-
-### progress\_info\_th
-
-```python
-progress_info_th(sock, thandle, msg, verbosity, attrs, links, path) ->
- None
-```
-
-While spans represents a pair of data points: start and stop; info events are instead singular events, one point in time. Call progress\_info() to write a progress span info event to the progress trace. The info event will have the same span-id as the start and stop events of the currently ongoing progress span in the active user session or transaction. See start\_progress\_span() for more information.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* msg -- message to report
-* verbosity -- VERBOSITY\_\*, default: VERBOSITY\_NORMAL (optional)
-* attrs -- user defined attributes (dict)
-* links -- to existing traces or spans \[{'trace\_id':'...', 'span\_id':'...'}]
-* path -- keypath to an action/leaf/service
-
-### pushd
-
-```python
-pushd(sock, thandle, path) -> None
-```
-
-Like cd, but saves the previous position in the tree. This can later be used by popd to return.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* path -- position to change to
-
-### query\_free\_result
-
-```python
-query_free_result(qrs) -> None
-```
-
-Deallocates the struct returned by 'query\_result()'.
-
-Keyword arguments:
-
-* qrs -- the query result structure to free
-
-### query\_reset
-
-```python
-query_reset(sock, qh) -> None
-```
-
-Reset the query to the beginning again.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* qh -- query handle
-
-### query\_reset\_to
-
-```python
-query_reset_to(sock, qh, offset) -> None
-```
-
-Reset the query to offset.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* qh -- query handle
-* offset -- offset counted from the beginning
-
-### query\_result
-
-```python
-query_result(sock, qh) -> _ncs.QueryResult
-```
-
-Fetches the next available chunk of results associated with query handle qh.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* qh -- query handle
-
-### query\_result\_count
-
-```python
-query_result_count(sock, qh) -> int
-```
-
-Counts the number of query results
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* qh -- query handle
-
-### query\_start
-
-```python
-query_start(sock, thandle, expr, context_node, chunk_size, initial_offset,
- result_as, select, sort) -> int
-```
-
-Starts a new query attached to the transaction given in 'th'. Returns a query handle.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* expr -- the XPath Path expression to evaluate
-* context\_node -- The context node (an ikeypath) for the primary expression, or None (which means that the context node will be /).
-* chunk\_size -- How many results to return at a time. If set to 0, a default number will be used.
-* initial\_offset -- Which result in line to begin with (1 means to start from the beginning).
-* result\_as -- The format the results will be returned in.
-* select -- An array of XPath 'select' expressions.
-* sort -- An array of XPath expressions which will be used for sorting
-
-### query\_stop
-
-```python
-query_stop(sock, qh) -> None
-```
-
-Stop the running query.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* qh -- query handle
-
-### rebind\_listener
-
-```python
-rebind_listener(sock, listener) -> None
-```
-
-Request that the subsystems specified by 'listeners' rebinds its listener socket(s).
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* listener -- One of the following parameters (ORed together if more than one)
-
- ```
- LISTENER_IPC
- LISTENER_NETCONF
- LISTENER_SNMP
- LISTENER_CLI
- LISTENER_WEBUI
- ```
-
-### reload\_config
-
-```python
-reload_config(sock) -> None
-```
-
-Request that the system reloads its configuration files.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### reopen\_logs
-
-```python
-reopen_logs(sock) -> None
-```
-
-Request that the system closes and re-opens its log files.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### report\_progress
-
-```python
-report_progress(sock, verbosity, msg) -> None
-```
-
-Report progress events.
-
-This function makes it possible to report transaction/action progress from user code.
-
-This function is deprecated and will be removed in a future release. Use progress\_info() instead.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* verbosity -- at which verbosity level the message should be reported
-* msg -- message to report
-
-### report\_progress2
-
-```python
-report_progress2(sock, verbosity, msg, package) -> None
-```
-
-Report progress events.
-
-This function makes it possible to report transaction/action progress from user code.
-
-This function is deprecated and will be removed in a future release. Use progress\_info() instead.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* verbosity -- at which verbosity level the message should be reported
-* msg -- message to report
-* package -- from what package the message is reported
-
-### report\_progress\_start
-
-```python
-report_progress_start(sock, verbosity, msg, package) -> int
-```
-
-Report progress events. Used for calculation of the duration between two events.
-
-This function makes it possible to report transaction/action progress from user code.
-
-This function is deprecated and will be removed in a future release. Use start\_progress\_span() instead.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* verbosity -- at which verbosity level the message should be reported
-* msg -- message to report
-* package -- from what package the message is reported (only NCS)
-
-### report\_progress\_stop
-
-```python
-report_progress_stop(sock, verbosity, msg, annotation,
- package, timestamp) -> int
-```
-
-Report progress events. Used for calculation of the duration between two events.
-
-This function makes it possible to report transaction/action progress from user code.
-
-This function is deprecated and will be removed in a future release. Use end\_progress\_span() instead.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* verbosity -- at which verbosity level the message should be reported
-* msg -- message to report
-* annotation -- metadata about the event, indicating error, explains latency or shows result etc
-* package -- from what package the message is reported (only NCS)
-* timestamp -- start of the event
-
-### report\_service\_progress
-
-```python
-report_service_progress(sock, verbosity, msg, path) -> None
-```
-
-Report progress events for a service.
-
-This function makes it possible to report transaction progress from FASTMAP code.
-
-This function is deprecated and will be removed in a future release. Use progress\_info() instead.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* verbosity -- at which verbosity level the message should be reported
-* msg -- message to report
-* path -- service instance path
-
-### report\_service\_progress2
-
-```python
-report_service_progress2(sock, verbosity, msg, package, path) -> None
-```
-
-Report progress events for a service.
-
-This function makes it possible to report transaction progress from FASTMAP code.
-
-This function is deprecated and will be removed in a future release. Use progress\_info() instead.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* verbosity -- at which verbosity level the message should be reported
-* msg -- message to report
-* package -- from what package the message is reported
-* path -- service instance path
-
-### report\_service\_progress\_start
-
-```python
-report_service_progress_start(sock, verbosity, msg, package, path) -> int
-```
-
-Report progress events for a service. Used for calculation of the duration between two events.
-
-This function makes it possible to report transaction progress from FASTMAP code.
-
-This function is deprecated and will be removed in a future release. Use start\_progress\_span() instead.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* verbosity -- at which verbosity level the message should be reported
-* msg -- message to report
-* package -- from what package the message is reported
-* path -- service instance path
-
-### report\_service\_progress\_stop
-
-```python
-report_service_progress_stop(sock, verbosity, msg, annotation,
- package, path) -> None
-```
-
-Report progress events for a service. Used for calculation of the duration between two events.
-
-This function makes it possible to report transaction progress from FASTMAP code.
-
-This function is deprecated and will be removed in a future release. Use end\_progress\_span() instead.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* verbosity -- at which verbosity level the message should be reported
-* msg -- message to report
-* annotation -- metadata about the event, indicating error, explains latency or shows result etc
-* package -- from what package the message is reported
-* path -- service instance path
-* timestamp -- start of the event
-
-### request\_action
-
-```python
-request_action(sock, params, hashed_ns, path) -> list
-```
-
-Invoke an action defined in the data model. Returns a list oftagValues.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* params -- tagValue parameters for the action
-* hashed\_ns -- namespace
-* path -- path to action
-
-### request\_action\_str\_th
-
-```python
-request_action_str_th(sock, thandle, cmd, path) -> str
-```
-
-The same as request\_action\_th but takes the parameters as a string and returns the result as a string.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* cmd -- string parameters
-* path -- path to action
-
-### request\_action\_th
-
-```python
-request_action_th(sock, thandle, params, path) -> list
-```
-
-Same as for request\_action() but uses the current namespace.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* params -- tagValue parameters for the action
-* path -- path to action
-
-### revert
-
-```python
-revert(sock, thandle) -> None
-```
-
-Removes all changes done to the transaction.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-
-### roll\_config
-
-```python
-roll_config(sock, thandle, path) -> int
-```
-
-This function can be used to save the equivalent of a rollback file for a given configuration before it is committed (or a subtree thereof) in curly bracket format. Returns an id
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* path -- tree for which to save the rollback configuration
-
-### roll\_config\_result
-
-```python
-roll_config_result(sock, id) -> int
-```
-
-We use this function to assert that we received the entire rollback configuration over a stream socket.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* id -- the id returned from roll\_config()
-
-### save\_config
-
-```python
-save_config(sock, thandle, flags, path) -> int
-```
-
-Save the config, returns an id. The flags parameter controls the saving as follows. The value is a bitmask.
-
-```
- CONFIG_XML -- The configuration format is XML.
- CONFIG_XML_PRETTY -- The configuration format is pretty printed XML.
- CONFIG_JSON -- The configuration is in JSON format.
- CONFIG_J -- The configuration is in curly bracket Juniper CLI
- format.
- CONFIG_C -- The configuration is in Cisco XR style format.
- CONFIG_TURBO_C -- The configuration is in Cisco XR style format.
- A faster parser than the normal CLI will be used.
- CONFIG_C_IOS -- The configuration is in Cisco IOS style format.
- CONFIG_XPATH -- The path gives an XPath filter instead of a
- keypath. Can only be used with CONFIG_XML and
- CONFIG_XML_PRETTY.
- CONFIG_WITH_DEFAULTS -- Default values are part of the
- configuration dump.
- CONFIG_SHOW_DEFAULTS -- Default values are also shown next to
- the real configuration value. Applies only to the CLI formats.
- CONFIG_WITH_OPER -- Include operational data in the dump.
- CONFIG_HIDE_ALL -- Hide all hidden nodes.
- CONFIG_UNHIDE_ALL -- Unhide all hidden nodes.
- CONFIG_WITH_SERVICE_META -- Include NCS service-meta-data
- attributes(refcounter, backpointer, out-of-band and
- original-value) in the dump.
- CONFIG_NO_PARENTS -- When a path is provided its parent nodes are by
- default included. With this option the output will begin
- immediately at path - skipping any parents.
- CONFIG_OPER_ONLY -- Include only operational data, and ancestors to
- operational data nodes, in the dump.
- CONFIG_NO_BACKQUOTE -- This option can only be used together with
- CONFIG_C and CONFIG_C_IOS. When set backslash will not be quoted
- in strings.
- CONFIG_CDB_ONLY -- Include only data stored in CDB in the dump. By
- default only configuration data is included, but the flag can be
- combined with either CONFIG_WITH_OPER or CONFIG_OPER_ONLY to
- save both configuration and operational data, or only
- operational data, respectively.
-```
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* flags -- as above
-* path -- save only configuration below path
-
-### save\_config\_result
-
-```python
-save_config_result(sock, id) -> None
-```
-
-Verify that we received the entire configuration over the stream socket.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* id -- the id returned from save\_config
-
-### set\_attr
-
-```python
-set_attr(sock, thandle, attr, v, keypath) -> None
-```
-
-Set attributes for a node.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* attr -- attributes to set
-* v -- value to set the attribute to
-* keypath -- path to choice
-
-### set\_comment
-
-```python
-set_comment(sock, thandle, comment) -> None
-```
-
-Set the Comment that is stored in the rollback file when a transaction towards running is committed.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* comment -- the Comment
-
-### set\_delayed\_when
-
-```python
-set_delayed_when(sock, thandle, on) -> None
-```
-
-This function enables (on non-zero) or disables (on == 0) the 'delayed when' mode of a transaction.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* on -- disables when on=0, enables for all other n
-
-### set\_elem
-
-```python
-set_elem(sock, thandle, v, path) -> None
-```
-
-Set element to confdValue.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* v -- confdValue
-* path -- position of elem
-
-### set\_elem2
-
-```python
-set_elem2(sock, thandle, strval, path) -> None
-```
-
-Set element to string.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* strval -- confdValue
-* path -- position of elem
-
-### set\_flags
-
-```python
-set_flags(sock, thandle, flags) -> None
-```
-
-Modify read/write session aspect. See MAAPI\_FLAG\_xyz.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* flags -- flags to set
-
-### set\_label
-
-```python
-set_label(sock, thandle, label) -> None
-```
-
-Set the Label that is stored in the rollback file when a transaction towards running is committed.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* label -- the Label
-
-### set\_namespace
-
-```python
-set_namespace(sock, thandle, hashed_ns) -> None
-```
-
-Indicate which namespace to use in case of ambiguities.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* hashed\_ns -- the namespace to use
-
-### set\_next\_user\_session\_id
-
-```python
-set_next_user_session_id(sock, usessid) -> None
-```
-
-Set the user session id that will be assigned to the next user session started. The given value is silently forced to be in the range 100 .. 2^31-1. This function can be used to ensure that session ids for user sessions started by northbound agents or via MAAPI are unique across a restart.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* usessid -- user session id
-
-### set\_object
-
-```python
-set_object(sock, thandle, values, keypath) -> None
-```
-
-Set leafs at path to object.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* values -- list of values
-* keypath -- path to set
-
-### set\_readonly\_mode
-
-```python
-set_readonly_mode(sock, flag) -> None
-```
-
-Control if northbound agents should be able to write or not.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* flag -- non-zero means read-only mode
-
-### set\_running\_db\_status
-
-```python
-set_running_db_status(sock, status) -> None
-```
-
-Sets the notion of consistent state of the running db.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* status -- integer status to set
-
-### set\_user\_session
-
-```python
-set_user_session(sock, usessid) -> None
-```
-
-Associate a socket with an already existing user session.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* usessid -- user session id
-
-### set\_values
-
-```python
-set_values(sock, thandle, values, keypath) -> None
-```
-
-Set leafs at path to values.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* values -- list of tagValues
-* keypath -- path to set
-
-### shared\_apply\_template
-
-```python
-shared_apply_template(sock, thandle, template, variables,flags, rootpath) -> None
-```
-
-FASTMAP version of ncs\_apply\_template.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* template -- template name
-* variables -- None or a list of variables in the form of tuples
-* flags -- Must be set as 0
-* rootpath -- in what context to apply the template
-
-### shared\_copy\_tree
-
-```python
-shared_copy_tree(sock, thandle, flags, frompath, topath) -> None
-```
-
-FASTMAP version of copy\_tree.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* flags -- Must be set as 0
-* frompath -- the path to copy the tree from
-* topath -- the path to copy the tree to
-
-### shared\_create
-
-```python
-shared_create(sock, thandle, flags, path) -> None
-```
-
-FASTMAP version of create.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* flags -- Must be set as 0
-
-### shared\_insert
-
-```python
-shared_insert(sock, thandle, flags, path) -> None
-```
-
-FASTMAP version of insert.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* flags -- Must be set as 0
-* path -- the path to the list to insert a new entry into
-
-### shared\_set\_elem
-
-```python
-shared_set_elem(sock, thandle, v, flags, path) -> None
-```
-
-FASTMAP version of set\_elem.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* v -- the value to set
-* flags -- should be 0
-* path -- the path to the element to set
-
-### shared\_set\_elem2
-
-```python
-shared_set_elem2(sock, thandle, strval, flags, path) -> None
-```
-
-FASTMAP version of set\_elem2.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* strval -- the value to se
-* flags -- should be 0
-* path -- the path to the element to set
-
-### shared\_set\_values
-
-```python
-shared_set_values(sock, thandle, values, flags, keypath) -> None
-```
-
-FASTMAP version of set\_values.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* values -- list of tagValues
-* flags -- should be 0
-* keypath -- path to set
-
-### snmpa\_reload
-
-```python
-snmpa_reload(sock, synchronous) -> None
-```
-
-Start a reload of SNMP Agent config from external data provider.
-
-Used by external data provider to notify that there is a change to the SNMP Agent config data. Calling the function with the argument 'synchronous' set to 1 or True means that the call will block until the loading is completed.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* synchronous -- if 1, will wait for the loading complete and return when the loading is complete; if 0, will only initiate the loading and return immediately
-
-### start\_phase
-
-```python
-start_phase(sock, phase, synchronous) -> None
-```
-
-When the system has been started in phase0, this function tells the system to proceed to start phase 1 or 2.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* phase -- phase to start, 1 or 2
-* synchronous -- if 1, will wait for the loading complete and return when the loading is complete; if 0, will only initiate the loading of AAA data and return immediately
-
-### start\_progress\_span
-
-```python
-start_progress_span(sock, msg, verbosity, attrs, links, path) -> dict
-```
-
-Starts a progress span. Progress spans are trace messages written to the progress trace and the developer log. A progress span consists of a start and a stop event which can be used to calculate the duration between the two. Those events can be identified with unique span-ids. Inside the span it is possible to start new spans, which will then become child spans, the parent-span-id is set to the previous spans' span-id. A child span can be used to calculate the duration of a sub task, and is started from consecutive maapi\_start\_progress\_span() calls, and is ended with maapi\_end\_progress\_span().
-
-The concepts of traces, trace-id and spans are highly influenced by https://opentelemetry.io/docs/concepts/signals/traces/#spans
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* msg -- message to report
-* verbosity -- VERBOSITY\_\*, default: VERBOSITY\_NORMAL (optional)
-* attrs -- user defined attributes (dict)
-* links -- to existing traces or spans \[{'trace\_id':'...', 'span\_id':'...'}]
-* path -- keypath to an action/leaf/service
-
-### start\_progress\_span\_th
-
-```python
-start_progress_span_th(sock, thandle, msg, verbosity,
- attrs, links, path) -> dict
-```
-
-Starts a progress span. Progress spans are trace messages written to the progress trace and the developer log. A progress span consists of a start and a stop event which can be used to calculate the duration between the two. Those events can be identified with unique span-ids. Inside the span it is possible to start new spans, which will then become child spans, the parent-span-id is set to the previous spans' span-id. A child span can be used to calculate the duration of a sub task, and is started from consecutive maapi\_start\_progress\_span() calls, and is ended with maapi\_end\_progress\_span().
-
-The concepts of traces, trace-id and spans are highly influenced by https://opentelemetry.io/docs/concepts/signals/traces/#spans
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* msg -- message to report
-* verbosity -- VERBOSITY\_\*, default: VERBOSITY\_NORMAL (optional)
-* attrs -- user defined attributes (dict)
-* links -- to existing traces or spans \[{'trace\_id':'...', 'span\_id':'...'}]
-* path -- keypath to an action/leaf/service
-
-### start\_trans
-
-```python
-start_trans(sock, name, readwrite) -> int
-```
-
-Creates a new transaction towards the data store specified by name, which can be one of CONFD\_CANDIDATE, CONFD\_RUNNING, or CONFD\_STARTUP (however updating the startup data store is better done via maapi\_copy\_running\_to\_startup()). The readwrite parameter can be either CONFD\_READ, to start a readonly transaction, or CONFD\_READ\_WRITE, to start a read-write transaction. The function returns the transaction id.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* name -- name of the database
-* readwrite -- CONFD\_READ or CONFD\_WRITE
-
-### start\_trans2
-
-```python
-start_trans2(sock, name, readwrite, usid) -> int
-```
-
-Start a transaction within an existing user session, returns the transaction id.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* name -- name of the database
-* readwrite -- CONFD\_READ or CONFD\_WRITE
-* usid -- user session id
-
-### start\_trans\_flags
-
-```python
-start_trans_flags(sock, name, readwrite, usid) -> int
-```
-
-The same as start\_trans2, but can also set the same flags that 'set\_flags' can set.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* name -- name of the database
-* readwrite -- CONFD\_READ or CONFD\_WRITE
-* usid -- user session id
-* flags -- same as for 'set\_flags'
-
-### start\_trans\_flags2
-
-```python
-start_trans_flags2(sock, name, readwrite, usid, vendor, product, version,
- client_id) -> int
-```
-
-This function does the same as start\_trans\_flags() but allows for additional information to be passed to ConfD/NCS.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* name -- name of the database
-* readwrite -- CONFD\_READ or CONFD\_WRITE
-* usid -- user session id
-* flags -- same as for 'set\_flags'
-* vendor -- vendor string (may be None)
-* product -- product string (may be None)
-* version -- version string (may be None)
-* client\_id -- client identification string (may be None)
-
-### start\_trans\_in\_trans
-
-```python
-start_trans_in_trans(sock, readwrite, usid, thandle) -> int
-```
-
-Start a transaction within an existing transaction, using the started transaction as backend instead of an actual data store. Returns the transaction id as an integer.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* readwrite -- CONFD\_READ or CONFD\_WRITE
-* usid -- user session id
-* thandle -- identifies the backend transaction to use
-
-### start\_user\_session
-
-```python
-start_user_session(sock, username, context, groups, src_addr, prot) -> None
-```
-
-Establish a user session on the socket.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* username -- the user for the session
-* context -- context for the session
-* groups -- groups
-* src-addr -- src address of e.g. the client connecting
-* prot -- the protocol used by the client for connecting
-
-### start\_user\_session2
-
-```python
-start_user_session2(sock, username, context, groups, src_addr, src_port, prot) -> None
-```
-
-Establish a user session on the socket.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* username -- the user for the session
-* context -- context for the session
-* groups -- groups
-* src-addr -- src address of e.g. the client connecting
-* src-port -- src port of e.g. the client connecting
-* prot -- the protocol used by the client for connecting
-
-### start\_user\_session3
-
-```python
-start_user_session3(sock, username, context, groups, src_addr, src_port, prot, vendor, product, version, client_id) -> None
-```
-
-Establish a user session on the socket.
-
-This function does the same as start\_user\_session2() but allows for additional information to be passed to ConfD/NCS.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* username -- the user for the session
-* context -- context for the session
-* groups -- groups
-* src-addr -- src address of e.g. the client connecting
-* src-port -- src port of e.g. the client connecting
-* prot -- the protocol used by the client for connecting
-* vendor -- vendor string (may be None)
-* product -- product string (may be None)
-* version -- version string (may be None)
-* client\_id -- client identification string (may be None)
-
-### start\_user\_session\_gen
-
-```python
-start_user_session_gen(sock, username, context, groups, vendor, product, version, client_id) -> None
-```
-
-Establish a user session on the socket.
-
-This function does the same as start\_user\_session3() but it takes the source address of the supplied socket from the OS.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* username -- the user for the session
-* context -- context for the session
-* groups -- groups
-* vendor -- vendor string (may be None)
-* product -- product string (may be None)
-* version -- version string (may be None)
-* client\_id -- client identification string (may be None)
-
-### stop
-
-```python
-stop(sock) -> None
-```
-
-Request that the system stops.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-
-### sys\_message
-
-```python
-sys_message(sock, to, message) -> None
-```
-
-Send a message to a specific user, a specific session or all user depending on the 'to' parameter. 'all', or can be used.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* to -- user to send message to or 'all' to send to all users
-* message -- the message
-
-### unhide\_group
-
-```python
-unhide_group(sock, thandle, group_name) -> None
-```
-
-Unhide all nodes belonging to a hide group in a transaction that started with flag FLAG\_HIDE\_ALL\_HIDEGROUPS.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* group\_name -- the group name
-
-### unlock
-
-```python
-unlock(sock, name) -> None
-```
-
-Unlock database with name.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* name -- name of the database to unlock
-
-### unlock\_partial
-
-```python
-unlock_partial(sock, lockid) -> None
-```
-
-Unlock a subset of a database which is locked by lockid.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* lockid -- id of the lock
-
-### user\_message
-
-```python
-user_message(sock, to, message, sender) -> None
-```
-
-Send a message to a specific user.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* to -- user to send message to or 'all' to send to all users
-* message -- the message
-* sender -- send as
-
-### validate\_trans
-
-```python
-validate_trans(sock, thandle, unlock, forcevalidation) -> None
-```
-
-Validates all data written in a transaction.
-
-If unlock is 1 (or True), the transaction is open for further editing even if validation succeeds. If unlock is 0 (or False) and the function returns CONFD\_OK, the next function to be called MUST be maapi\_prepare\_trans() or maapi\_finish\_trans().
-
-unlock = 1 can be used to implement a 'validate' command which can be given in the middle of an editing session. The first thing that happens is that a lock is set. If unlock == 1, the lock is released on success. The lock is always released on failure.
-
-The forcevalidation argument should normally be 0 (or False). It has no effect for a transaction towards the running or startup data stores, validation is always performed. For a transaction towards the candidate data store, validation will not be done unless forcevalidation is non-zero.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* unlock -- int or bool
-* forcevalidation -- int or bool
-
-### wait\_start
-
-```python
-wait_start(sock, phase) -> None
-```
-
-Wait for the system to reach a certain start phase (0,1 or 2).
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* phase -- phase to wait for, 0, 1 or 2
-
-### write\_service\_log\_entry
-
-```python
-write_service_log_entry(sock, path, msg, type, level) -> None
-```
-
-Write service log entries.
-
-This function makes it possible to write service log entries from FASTMAP code.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* path -- service instance path
-* msg -- message to log
-* type -- log entry type
-* level -- log entry level
-
-### xpath2kpath
-
-```python
-xpath2kpath(sock, xpath) -> _ncs.HKeypathRef
-```
-
-Convert an xpath to a hashed keypath.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* xpath -- to convert
-
-### xpath2kpath\_th
-
-```python
-xpath2kpath_th(sock, thandle, xpath) -> _ncs.HKeypathRef
-```
-
-Convert an xpath to a hashed keypath.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* xpath -- to convert
-
-### xpath\_eval
-
-```python
-xpath_eval(sock, thandle, expr, result, trace, path) -> None
-```
-
-Evaluate the xpath expression in 'expr'. For each node in the resulting node the function 'result' is called with the keypath to the resulting node as the first argument and, if the node is a leaf and has a value. the value of that node as the second argument. For each invocation of 'result' the function should return ITER\_CONTINUE to tell the XPath evaluator to continue or ITER\_STOP to stop the evaluation. A trace function, 'pytrace', could be supplied and will be called with a single string as an argument. 'None' can be used if no trace is needed. Unless a 'path' is given the root node will be used as a context for the evaluations.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* expr -- the XPath Path expression to evaluate
-* result -- the result function
-* trace -- a trace function that takes a string as a parameter
-* path -- the context node
-
-### xpath\_eval\_expr
-
-```python
-xpath_eval_expr(sock, thandle, expr, trace, path) -> str
-```
-
-Like xpath\_eval but returns a string.
-
-Keyword arguments:
-
-* sock -- a python socket instance
-* thandle -- transaction handle
-* expr -- the XPath Path expression to evaluate
-* trace -- a trace function that takes a string as a parameter
-* path -- the context node
-
-## Classes
-
-### _class_ **Cursor**
-
-struct maapi\_cursor object
-
-Members:
-
-_None_
-
-## Predefined Values
-
-```python
-
-CMD_KEEP_PIPE = 8
-CMD_NO_AAA = 4
-CMD_NO_FULLPATH = 1
-CMD_NO_HIDDEN = 2
-COMMIT_NCS_ASYNC_COMMIT_QUEUE = 256
-COMMIT_NCS_BYPASS_COMMIT_QUEUE = 64
-COMMIT_NCS_CONFIRM_NETWORK_STATE = 268435456
-COMMIT_NCS_CONFIRM_NETWORK_STATE_RE_EVALUATE_POLICIES = 536870912
-COMMIT_NCS_NO_DEPLOY = 8
-COMMIT_NCS_NO_FASTMAP = 8
-COMMIT_NCS_NO_LSA = 1048576
-COMMIT_NCS_NO_NETWORKING = 16
-COMMIT_NCS_NO_OUT_OF_SYNC_CHECK = 32
-COMMIT_NCS_NO_OVERWRITE = 1024
-COMMIT_NCS_NO_REVISION_DROP = 4
-COMMIT_NCS_RECONCILE_ATTACH_NON_SERVICE_CONFIG = 67108864
-COMMIT_NCS_RECONCILE_DETACH_NON_SERVICE_CONFIG = 134217728
-COMMIT_NCS_RECONCILE_DISCARD_NON_SERVICE_CONFIG = 33554432
-COMMIT_NCS_RECONCILE_KEEP_NON_SERVICE_CONFIG = 16777216
-COMMIT_NCS_SYNC_COMMIT_QUEUE = 512
-COMMIT_NCS_USE_LSA = 524288
-CONFIG_AUTOCOMMIT = 8192
-CONFIG_C = 4
-CONFIG_CDB_ONLY = 4194304
-CONFIG_CONTINUE_ON_ERROR = 16384
-CONFIG_C_IOS = 32
-CONFIG_HIDE_ALL = 2048
-CONFIG_J = 2
-CONFIG_JSON = 131072
-CONFIG_MERGE = 64
-CONFIG_NO_BACKQUOTE = 2097152
-CONFIG_NO_PARENTS = 524288
-CONFIG_OPER_ONLY = 1048576
-CONFIG_READ_WRITE_ACCESS_ONLY = 33554432
-CONFIG_REPLACE = 1024
-CONFIG_SHOW_DEFAULTS = 16
-CONFIG_SUPPRESS_ERRORS = 32768
-CONFIG_TURBO_C = 8388608
-CONFIG_UNHIDE_ALL = 4096
-CONFIG_WITH_DEFAULTS = 8
-CONFIG_WITH_OPER = 128
-CONFIG_WITH_SERVICE_META = 262144
-CONFIG_XML = 1
-CONFIG_XML_LOAD_LAX = 65536
-CONFIG_XML_PRETTY = 512
-CONFIG_XPATH = 256
-DEL_ALL = 2
-DEL_EXPORTED = 3
-DEL_SAFE = 1
-ECHO = 1
-FLAG_CONFIG_CACHE_ONLY = 32
-FLAG_CONFIG_ONLY = 4
-FLAG_DELAYED_WHEN = 64
-FLAG_DELETE = 2
-FLAG_EMIT_PARENTS = 1
-FLAG_HIDE_ALL_HIDEGROUPS = 256
-FLAG_HIDE_INACTIVE = 8
-FLAG_HINT_BULK = 1
-FLAG_NON_RECURSIVE = 4
-FLAG_NO_CONFIG_CACHE = 16
-FLAG_NO_DEFAULTS = 2
-FLAG_SKIP_SUBSCRIBERS = 512
-MOVE_AFTER = 3
-MOVE_BEFORE = 2
-MOVE_FIRST = 1
-MOVE_LAST = 4
-NOECHO = 0
-PRODUCT = 'NCS'
-UPGRADE_KILL_ON_TIMEOUT = 1
-```
diff --git a/developer-reference/pyapi/_ncs.md b/developer-reference/pyapi/_ncs.md
deleted file mode 100644
index cda0def3..00000000
--- a/developer-reference/pyapi/_ncs.md
+++ /dev/null
@@ -1,2179 +0,0 @@
-# \_ncs Module
-
-NCS Python low level module.
-
-This module and its submodules provide Python bindings for the C APIs, described by the [confd\_lib(3)](../../resources/man/confd_lib.3.md) man page.
-
-The companion high level module, ncs, provides an abstraction layer on top of this module and may be easier to use.
-
-## Submodules
-
-* [\_ncs.cdb](_ncs.cdb.md): Low level module for connecting to NCS built-in XML database (CDB).
-* [\_ncs.dp](_ncs.dp.md): Low level callback module for connecting data providers to NCS.
-* [\_ncs.error](_ncs.error.md): This module defines new NCS Python API exception classes.
-* [\_ncs.events](_ncs.events.md): Low level module for subscribing to NCS event notifications.
-* [\_ncs.ha](_ncs.ha.md): Low level module for connecting to NCS HA subsystem.
-* [\_ncs.maapi](_ncs.maapi.md): Low level module for connecting to NCS with a read/write interface inside transactions.
-
-## Functions
-
-### cs\_node\_cd
-
-```python
-cs_node_cd(start, path) -> Union[CsNode, None]
-```
-
-Utility function which finds the resulting CsNode given an (optional) starting node and a (relative or absolute) string keypath.
-
-Keyword arguments:
-
-* start -- a CsNode instance or None
-* path -- the path
-
-### decrypt
-
-```python
-decrypt(ciphertext) -> str
-```
-
-When data is read over the CDB interface, the MAAPI interface or received in event notifications, the data for the builtin types tailf:aes-cfb-128-encrypted-string and tailf:aes-256-cfb-128-encrypted-string is encrypted. This function decrypts ciphertext and returns the clear text as a string.
-
-Keyword arguments:
-
-* ciphertext -- encrypted string
-
-### expr\_op2str
-
-```python
-expr_op2str(op) -> str
-```
-
-Convert confd\_expr\_op value to a string.
-
-Keyword arguments:
-
-* op -- confd\_expr\_op integer value
-
-### fatal
-
-```python
-fatal(str) -> None
-```
-
-Utility function which formats a string, prints it to stderr and exits with exit code 1. This function will never return.
-
-Keyword arguments:
-
-* str -- a message string
-
-### find\_cs\_node
-
-```python
-find_cs_node(hkeypath, len) -> Union[CsNode, None]
-```
-
-Utility function which finds the CsNode corresponding to the len first elements of the hashed keypath. To make the search consider the full keypath leave out the len parameter.
-
-Keyword arguments:
-
-* hkeypath -- a HKeypathRef instance
-* len -- number of elements to return (optional)
-
-### find\_cs\_node\_child
-
-```python
-find_cs_node_child(parent, xmltag) -> Union[CsNode, None]
-```
-
-Utility function which finds the CsNode corresponding to the child node given as xmltag.
-
-See confd\_find\_cs\_node\_child() in [confd\_lib\_lib(3)](../../resources/man/confd_lib_lib.3.md).
-
-Keyword arguments:
-
-* parent -- the parent CsNode
-* xmltag -- the child node
-
-### find\_cs\_root
-
-```python
-find_cs_root(ns) -> Union[CsNode, None]
-```
-
-When schema information is available to the library, this function returns the root of the tree representaton of the namespace given by ns for the (first) toplevel node. For namespaces that are augmented into other namespaces such that they do not have a toplevel node, this function returns None - the nodes of such a namespace are found below the augment target node(s) in other tree(s).
-
-Keyword arguments:
-
-* ns -- the namespace id
-
-### find\_ns\_type
-
-```python
-find_ns_type(nshash, name) -> Union[CsType, None]
-```
-
-Returns a CsType type definition for the type named name, which is defined in the namespace identified by nshash, or None if the type could not be found. If nshash is 0, the type name will be looked up among the built-in types (i.e. the YANG built-in types, the types defined in the YANG "tailf-common" module, and the types defined in the "confd" and "xs" namespaces).
-
-Keyword arguments:
-
-* nshash -- a namespace hash or 0 (0 searches for built-in types)
-* name -- the name of the type
-
-### get\_leaf\_list\_type
-
-```python
-get_leaf_list_type(node) -> CsType
-```
-
-For a leaf-list node, the type() method in the CsNodeInfo identifies a "list type" for the leaf-list "itself". This function returns the type of the elements in the leaf-list, i.e. corresponding to the type substatement for the leaf-list in the YANG module.
-
-Keyword arguments:
-
-* node -- The CsNode of the leaf-list
-
-### get\_nslist
-
-```python
-get_nslist() -> list
-```
-
-Provides a list of the namespaces known to the library as a list of five-tuples. Each tuple contains the the namespace hash (int), the prefix (string), the namespace uri (string), the revision (string), and the module name (string).
-
-If schemas are not loaded an empty list will be returned.
-
-### hash2str
-
-```python
-hash2str(hash) -> Union[str, None]
-```
-
-Returns a string representing the node name given by hash, or None if the hash value is not found. Requires that schema information has been loaded from the NCS daemon into the library - otherwise it always returns None.
-
-Keyword arguments:
-
-* hash -- a hash
-
-### hkeypath\_dup
-
-```python
-hkeypath_dup(hkeypath) -> HKeypathRef
-```
-
-Duplicates a HKeypathRef object.
-
-Keyword arguments:
-
-* hkeypath -- a HKeypathRef instance
-
-### hkeypath\_dup\_len
-
-```python
-hkeypath_dup_len(hkeypath, len) -> HKeypathRef
-```
-
-Duplicates the first len elements of hkeypath.
-
-Keyword arguments:
-
-* hkeypath -- a HKeypathRef instance
-* len -- number of elements to include in the copy
-
-### hkp\_prefix\_tagmatch
-
-```python
-hkp_prefix_tagmatch(hkeypath, tags) -> bool
-```
-
-A simplified version of hkp\_tagmatch() - it returns True if the tagpath matches a prefix of the hkeypath, i.e. it is equivalent to calling hkp\_tagmatch() and checking if the return value includes CONFD\_HKP\_MATCH\_TAGS.
-
-Keyword arguments:
-
-* hkeypath -- a HKeypathRef instance
-* tags -- a list of XmlTag instances
-
-### hkp\_tagmatch
-
-```python
-hkp_tagmatch(hkeypath, tags) -> int
-```
-
-When checking the hkeypaths that get passed into each iteration in e.g. cdb\_diff\_iterate() we can either explicitly check the paths, or use this function to do the job. The tags list (typically statically initialized) specifies a tagpath to match against the hkeypath. See cdb\_diff\_match().
-
-Keyword arguments:
-
-* hkeypath -- a HKeypathRef instance
-* tags -- a list of XmlTag instances
-
-### init
-
-```python
-init(name, file, level) -> None
-```
-
-Initializes the ConfD library. Must be called before any other NCS API functions are called. There should be no need to call this function directly. It is called internally when the Python module is loaded.
-
-Keyword arguments:
-
-* name -- e
-* file -- (optional)
-* level -- (optional)
-
-### internal\_connect
-
-```python
-internal_connect(id, sock, ip, port, path) -> None
-```
-
-Internal function used by NCS Python VM.
-
-### list\_filter\_type2str
-
-```python
-list_filter_type2str(op) -> str
-```
-
-Convert confd\_list\_filter\_type value to a string.
-
-Keyword arguments:
-
-* type -- confd\_list\_filter\_type integer value
-
-### max\_object\_size
-
-```python
-max_object_size(object) -> int
-```
-
-Utility function which returns the maximum size (i.e. the needed length of the confd\_value\_t array) for an "object" retrieved by cdb\_get\_object(), maapi\_get\_object(), and corresponding multi-object functions.
-
-Keyword arguments:
-
-* object -- the CsNode
-
-### mmap\_schemas
-
-```python
-mmap_schemas(filename) -> None
-```
-
-If shared memory schema support has been enabled, this function will will map a shared memory segment into the current process address space and make it ready for use.
-
-The filename can be obtained by using the get\_schema\_file\_path() function
-
-The filename argument specifies the pathname of the file that is used as backing store.
-
-Keyword arguments:
-
-* filename -- a filename string
-
-### next\_object\_node
-
-```python
-next_object_node(object, cur, value) -> Union[CsNode, None]
-```
-
-Utility function to allow navigation of the confd\_cs\_node schema tree in parallel with the confd\_value\_t array populated by cdb\_get\_object(), maapi\_get\_object(), and corresponding multi-object functions.
-
-The cur parameter is the CsNode for the current value, and the value parameter is the current value in the array. The function returns a CsNode for the next value in the array, or None when the complete object has been traversed. In the initial call for a given traversal, we must pass self.children() for the cur parameter - this always points to the CsNode for the first value in the array.
-
-Keyword arguments:
-
-* object -- CsNode of the list container node
-* cur -- The CsNode of the current value
-* value -- The current value
-
-### ns2prefix
-
-```python
-ns2prefix(ns) -> Union[str, None]
-```
-
-Returns a string giving the namespace prefix for the namespace ns, if the namespace is known to the library - otherwise it returns None.
-
-Keyword arguments:
-
-* ns -- a namespace hash
-
-### pp\_kpath
-
-```python
-pp_kpath(hkeypath) -> str
-```
-
-Utility function which pretty prints a string representation of the path hkeypath. This will use the NCS curly brace notation, i.e. "/servers/server{www}/ip". Requires that schema information is available to the library.
-
-Keyword arguments:
-
-* hkeypath -- a HKeypathRef instance
-
-### pp\_kpath\_len
-
-```python
-pp_kpath_len(hkeypath, len) -> str
-```
-
-A variant of pp\_kpath() that prints only the first len elements of hkeypath.
-
-Keyword arguments:
-
-* hkeypath -- a \_lib.HKeypathRef instance
-* len -- number of elements to print
-
-### set\_debug
-
-```python
-set_debug(level, file) -> None
-```
-
-Sets the debug level
-
-Keyword arguments:
-
-* file -- (optional)
-* level -- (optional)
-
-### set\_kill\_child\_on\_parent\_exit
-
-```python
-set_kill_child_on_parent_exit() -> bool
-```
-
-Instruct the operating system to kill this process if the parent process exits.
-
-### str2hash
-
-```python
-str2hash(str) -> int
-```
-
-Returns the hash value representing the node name given by str, or 0 if the string is not found. Requires that schema information has been loaded from the NCS daemon into the library - otherwise it always returns 0.
-
-Keyword arguments:
-
-* str -- a name string
-
-### stream\_connect
-
-```python
-stream_connect(sock, id, flags, ip, port, path) -> None
-```
-
-Connects a stream socket to NCS.
-
-Keyword arguments:
-
-* sock -- a Python socket instance
-* id -- id
-* flags -- flags
-* ip -- ip address - if sock family is AF\_INET or AF\_INET6 (optional)
-* port -- port - if sock family is AF\_INET or AF\_INET6 (optional)
-* path -- a filename - if sock family is AF\_UNIX (optional)
-
-### xpath\_pp\_kpath
-
-```python
-xpath_pp_kpath(hkeypath) -> str
-```
-
-Utility function which pretty prints a string representation of the path hkeypath. This will format the path as an XPath, i.e. "/servers/server\[name="www"']/ip". Requires that schema information is available to the library.
-
-Keyword arguments:
-
-* hkeypath -- a HKeypathRef instance
-
-## Classes
-
-### _class_ **AttrValue**
-
-This type represents the c-type confd\_attr\_value\_t.
-
-The contructor for this type has the following signature:
-
-AttrValue(attr, v) -> object
-
-Keyword arguments:
-
-* attr -- attribute type
-* v -- value
-
-Members:
-
-with_traceback(...)
- -Method: - -Exception.with_traceback(tb) -- -set self.__traceback__ to tb and return self. - -
-
-
-
-attr
- -attribute type (int) - -
-
-
-
-### _class_ **AuthorizationInfo**
-
-This type represents the c-type struct confd\_authorization\_info.
-
-AuthorizationInfo cannot be directly instantiated from Python.
-
-Members:
-
-v
- -attribute value (Value) - -
-
-
-
-### _class_ **CsCase**
-
-This type represents the c-type struct confd\_cs\_case.
-
-CsCase cannot be directly instantiated from Python.
-
-Members:
-
-groups
- -authorization groups (list of strings) - -
-
-
-
-choices(...)
- -Method: - -```python -choices() -> Union[CsChoice, None] -``` - -Returns the CsCase choices. - -
-
-
-
-first(...)
- -Method: - -```python -first() -> Union[CsNode, None] -``` - -Returns the CsCase first. - -
-
-
-
-last(...)
- -Method: - -```python -last() -> Union[CsNode, None] -``` - -Returns the CsCase last. - -
-
-
-
-next(...)
- -Method: - -```python -next() -> Union[CsCase, None] -``` - -Returns the CsCase next. - -
-
-
-
-ns(...)
- -Method: - -```python -ns() -> int -``` - -Returns the CsCase ns hash. - -
-
-
-
-parent(...)
- -Method: - -```python -parent() -> Union[CsChoice, None] -``` - -Returns the CsCase parent. - -
-
-
-
-### _class_ **CsChoice**
-
-This type represents the c-type struct confd\_cs\_choice.
-
-CsChoice cannot be directly instantiated from Python.
-
-Members:
-
-tag(...)
- -Method: - -```python -tag() -> int -``` - -Returns the CsCase tag hash. - -
-
-
-
-case_parent(...)
- -Method: - -```python -case_parent() -> Union[CsCase, None] -``` - -Returns the CsChoice case parent. - -
-
-
-
-cases(...)
- -Method: - -```python -cases() -> Union[CsCase, None] -``` - -Returns the CsChoice cases. - -
-
-
-
-default_case(...)
- -Method: - -```python -default_case() -> Union[CsCase, None] -``` - -Returns the CsChoice default case. - -
-
-
-
-min_occurs(...)
- -Method: - -```python -min_occurs() -> int -``` - -Returns the CsChoice minOccurs. - -
-
-
-
-next(...)
- -Method: - -```python -next() -> Union[CsChoice, None] -``` - -Returns the CsChoice next. - -
-
-
-
-ns(...)
- -Method: - -```python -ns() -> int -``` - -Returns the CsChoice ns hash. - -
-
-
-
-parent(...)
- -Method: - -```python -parent() -> Union[CsNode, None] -``` - -Returns the CsChoice parent CsNode. - -
-
-
-
-### _class_ **CsNode**
-
-This type represents the c-type struct confd\_cs\_node.
-
-CsNode cannot be directly instantiated from Python.
-
-Members:
-
-tag(...)
- -Method: - -```python -tag() -> int -``` - -Returns the CsChoice tag hash. - -
-
-
-
-children(...)
- -Method: - -```python -children() -> Union[CsNode, None] -``` - -Returns the children CsNode or None. - -
-
-
-
-has_display_when(...)
- -Method: - -```python -has_display_when() -> bool -``` - -Returns True if CsNode has YANG 'tailf:display-when' statement(s). - -
-
-
-
-has_when(...)
- -Method: - -```python -has_when() -> bool -``` - -Returns True if CsNode has YANG 'when' statement(s). - -
-
-
-
-info(...)
- -Method: - -```python -info() -> CsNodeInfo -``` - -Returns a CsNodeInfo. - -
-
-
-
-is_action(...)
- -Method: - -```python -is_action() -> bool -``` - -Returns True if CsNode is an action. - -
-
-
-
-is_action_param(...)
- -Method: - -```python -is_action_param() -> bool -``` - -Returns True if CsNode is an action parameter. - -
-
-
-
-is_action_result(...)
- -Method: - -```python -is_action_result() -> bool -``` - -Returns True if CsNode is an action result. - -
-
-
-
-is_case(...)
- -Method: - -```python -is_case() -> bool -``` - -Returns True if CsNode is a case. - -
-
-
-
-is_container(...)
- -Method: - -```python -is_container() -> bool -``` - -Returns True if CsNode is a container. - -
-
-
-
-is_empty_leaf(...)
- -Method: - -```python -is_empty_leaf() -> bool -``` - -Returns True if CsNode is a leaf which is empty. - -
-
-
-
-is_key(...)
- -Method: - -```python -is_key() -> bool -``` - -Returns True if CsNode is a key. - -
-
-
-
-is_leaf(...)
- -Method: - -```python -is_leaf() -> bool -``` - -Returns True if CsNode is a leaf. - -
-
-
-
-is_leaf_list(...)
- -Method: - -```python -is_leaf_list() -> bool -``` - -Returns True if CsNode is a leaf-list. - -
-
-
-
-is_leafref(...)
- -Method: - -```python -is_leafref() -> bool -``` - -Returns True if CsNode is a YANG 'leafref'. - -
-
-
-
-is_list(...)
- -Method: - -```python -is_list() -> bool -``` - -Returns True if CsNode is a list. - -
-
-
-
-is_mount_point(...)
- -Method: - -```python -is_mount_point() -> bool -``` - -Returns True if CsNode is a mount point. - -
-
-
-
-is_non_empty_leaf(...)
- -Method: - -```python -is_non_empty_leaf() -> bool -``` - -Returns True if CsNode is a leaf which is not of type empty. - -
-
-
-
-is_notif(...)
- -Method: - -```python -is_notif() -> bool -``` - -Returns True if CsNode is a notification. - -
-
-
-
-is_np_container(...)
- -Method: - -```python -is_np_container() -> bool -``` - -Returns True if CsNode is a non presence container. - -
-
-
-
-is_oper(...)
- -Method: - -```python -is_oper() -> bool -``` - -Returns True if CsNode is OPER data. - -
-
-
-
-is_p_container(...)
- -Method: - -```python -is_p_container() -> bool -``` - -Returns True if CsNode is a presence container. - -
-
-
-
-is_union(...)
- -Method: - -```python -is_union() -> bool -``` - -Returns True if CsNode is a union. - -
-
-
-
-is_writable(...)
- -Method: - -```python -is_writable() -> bool -``` - -Returns True if CsNode is writable. - -
-
-
-
-next(...)
- -Method: - -```python -next() -> Union[CsNode, None] -``` - -Returns the next CsNode or None. - -
-
-
-
-ns(...)
- -Method: - -```python -ns() -> int -``` - -Returns the namespace value. - -
-
-
-
-parent(...)
- -Method: - -```python -parent() -> Union[CsNode, None] -``` - -Returns the parent CsNode or None. - -
-
-
-
-### _class_ **CsNodeInfo**
-
-This type represents the c-type struct confd\_cs\_node\_info.
-
-CsNodeInfo cannot be directly instantiated from Python.
-
-Members:
-
-tag(...)
- -Method: - -```python -tag() -> int -``` - -Returns the tag value. - -
-
-
-
-choices(...)
- -Method: - -```python -choices() -> Union[CsChoice, None] -``` - -Returns CsNodeInfo choices. - -
-
-
-
-cmp(...)
- -Method: - -```python -cmp() -> int -``` - -Returns CsNodeInfo cmp. - -
-
-
-
-defval(...)
- -Method: - -```python -defval() -> Value -``` - -Returns CsNodeInfo value. - -
-
-
-
-flags(...)
- -Method: - -```python -flags() -> int -``` - -Returns CsNodeInfo flags. - -
-
-
-
-keys(...)
- -Method: - -```python -keys() -> List[int] -``` - -Returns a list of hashed key values. - -
-
-
-
-max_occurs(...)
- -Method: - -```python -max_occurs() -> int -``` - -Returns CsNodeInfo max\_occurs. - -
-
-
-
-meta_data(...)
- -Method: - -```python -meta_data() -> Union[Dict, None] -``` - -Returns CsNodeInfo meta\_data. - -
-
-
-
-min_occurs(...)
- -Method: - -```python -min_occurs() -> int -``` - -Returns CsNodeInfo min\_occurs. - -
-
-
-
-shallow_type(...)
- -Method: - -```python -shallow_type() -> int -``` - -Returns CsNodeInfo shallow\_type. - -
-
-
-
-### _class_ **CsType**
-
-This type represents the c-type struct confd\_type.
-
-CsType cannot be directly instantiated from Python.
-
-Members:
-
-type(...)
- -Method: - -```python -type() -> int -``` - -Returns CsNodeInfo type. - -
-
-
-
-bitbig_size(...)
- -Method: - -```python -bitbig_size() -> int -``` - -Returns the maximum size needed for the byte array for the BITBIG value when a YANG bits type has a highest position above 63. If this is not a BITBIG value or if the highest position is 63 or less, this function will return 0. - -
-
-
-
-defval(...)
- -Method: - -```python -defval() -> Union[CsType, None] -``` - -Returns the CsType defval. - -
-
-
-
-### _class_ **DateTime**
-
-This type represents the c-type struct confd\_datetime.
-
-The contructor for this type has the following signature:
-
-DateTime(year, month, day, hour, min, sec, micro, timezone, timezone\_minutes) -> object
-
-Keyword arguments:
-
-* year -- the year (int)
-* month -- the month (int)
-* day -- the day (int)
-* hour -- the hour (int)
-* min -- minutes (int)
-* sec -- seconds (int)
-* micro -- micro seconds (int)
-* timezone -- the timezone (int)
-* timezone\_minutes -- number of timezone\_minutes (int)
-
-Members:
-
-parent(...)
- -Method: - -```python -parent() -> Union[CsType, None] -``` - -Returns the CsType parent. - -
-
-
-
-day
- -the day - -
-
-
-
-hour
- -the hour - -
-
-
-
-micro
- -micro seconds - -
-
-
-
-min
- -minutes - -
-
-
-
-month
- -the month - -
-
-
-
-sec
- -seconds - -
-
-
-
-timezone
- -timezone - -
-
-
-
-timezone_minutes
- -timezone minutes - -
-
-
-
-### _class_ **HKeypathRef**
-
-This type represents the c-type confd\_hkeypath\_t.
-
-HKeypathRef implements some sequence methods which enables indexing, iteration and length checking. There is also support for slicing, e.g:
-
-Lets say the variable hkp is a valid hkeypath pointing to '/foo/bar{a}/baz' and we slice that object like this:
-
-```
-newhkp = hkp[1:]
-```
-
-In this case newhkp will be a new hkeypath pointing to '/foo/bar{a}'. Note that the last element must always be included, so trying to create a slice with hkp\[1:2] will fail.
-
-The example above could also be written using the dup\_len() method:
-
-```
-newhkp = hkp.dup_len(3)
-```
-
-Retrieving an element of the HKeypathRef when the underlying Value is of type C\_XMLTAG returns a XmlTag instance. In all other cases a tuple of Values is returned.
-
-When receiving an HKeypathRef object as on argument in a callback method, the underlying object is only borrowed, so this particular instance is only valid inside that callback method. If one, for some reason, would like to keep the HKeypathRef object 'alive' for any longer than that, use dup() or dup\_len() to get a copy of it. Slicing also creates a copy.
-
-HKeypathRef cannot be directly instantiated from Python.
-
-Members:
-
-year
- -the year - -
-
-
-
-dup(...)
- -Method: - -```python -dup() -> HKeypathRef -``` - -Duplicates this hkeypath. - -
-
-
-
-### _class_ **ProgressLink**
-
-This type represents the c-type struct confd\_progress\_link.
-
-confdProgressLink cannot be directly instantiated from Python.
-
-Members:
-
-dup_len(...)
- -Method: - -```python -dup_len(len) -> HKeypathRef -``` - -Duplicates the first len elements of this hkeypath. - -Keyword arguments: - -* len -- number of elements to include in the copy - -
-
-
-
-span_id
- -span id (string) - -
-
-
-
-### _class_ **QueryResult**
-
-This type represents the c-type struct confd\_query\_result.
-
-QueryResult implements some sequence methods which enables indexing, iteration and length checking.
-
-QueryResult cannot be directly instantiated from Python.
-
-Members:
-
-trace_id
- -trace id (string) - -
-
-
-
-nelements
- -number of elements (int) - -
-
-
-
-nresults
- -number of results (int) - -
-
-
-
-offset
- -the offset (int) - -
-
-
-
-### _class_ **SnmpVarbind**
-
-This type represents the c-type struct confd\_snmp\_varbind.
-
-The contructor for this type has the following signature:
-
-SnmpVarbind(type, val, vartype, name, oid, cr) -> object
-
-Keyword arguments:
-
-* type -- SNMP\_VARIABLE, SNMP\_OID or SNMP\_COL\_ROW (int)
-* val -- value (Value)
-* vartype -- snmp type (optional)
-* name -- mandatory if type is SNMP\_VARIABLE (string)
-* oid -- mandatory if type is SNMP\_OID (list of integers)
-* cr -- mandatory if type is SNMP\_COL\_ROW (described below)
-
-When type is SNMP\_COL\_ROW the cr argument must be provided. It is built up as a 2-tuple like this: tuple(string, list(int)).
-
-The first element of the 2-tuple is the column name.
-
-The second element (the row index) is a list of up to 128 integers.
-
-Members:
-
-type
- -the query result type (int) - -
-
-
-
-### _class_ **TagValue**
-
-This type represents the c-type confd\_tag\_value\_t.
-
-In addition to the 'ns' and 'tag' attributes there is an additional attribute 'v' which containes the Value object.
-
-The contructor for this type has the following signature:
-
-TagValue(xmltag, v, tag, ns) -> object
-
-There are two ways to contruct this object. The first one requires that both xmltag and v are specified. The second one requires that both tag and ns are specified.
-
-Keyword arguments:
-
-* xmltag -- a XmlTag instance (optional)
-* v -- a Value instance (optional)
-* tag -- tag hash (optional)
-* ns -- namespace hash (optional)
-
-Members:
-
-type
- -the SnmpVarbind type - -
-
-
-
-ns
- -namespace hash - -
-
-
-
-### _class_ **TransCtxRef**
-
-This type represents the c-type struct confd\_trans\_ctx.
-
-Available attributes:
-
-* fd -- worker socket (int)
-* th -- transaction handle (int)
-* secondary\_index -- secondary index number for list traversal (int)
-* username -- from user session (string) DEPRECATED, see uinfo
-* context -- from user session (string) DEPRECATED, see uinfo
-* uinfo -- user session (UserInfo)
-* accumulated -- if the data provider is using the accumulate functionality this attribute will contain the first dp.TrItemRef object in the linked list, otherwise if will be None
-* traversal\_id -- unique id for the get\_next\* invocation
-
-TransCtxRef cannot be directly instantiated from Python.
-
-Members:
-
-_None_
-
-### _class_ **UserInfo**
-
-This type represents the c-type struct confd\_user\_info.
-
-UserInfo cannot be directly instantiated from Python.
-
-Members:
-
-tag
- -tag hash - -
-
-
-
-actx_thandle
- -actx\_thandle -- action context transaction handle - -
-
-
-
-addr
- -addr -- ip address (string) - -
-
-
-
-af
- -af -- address family AF\_INIT or AF\_INET6 (int) - -
-
-
-
-clearpass
- -clearpass -- password if available (string) - -
-
-
-
-context
- -context -- the context (string) - -
-
-
-
-flags
- -flags -- CONFD\_USESS\_FLAG\_... (int) - -
-
-
-
-lmode
- -lmode -- the lock we have (int) - -
-
-
-
-logintime
- -logintime -- time for login (long) - -
-
-
-
-port
- -port -- source port (int) - -
-
-
-
-proto
- -proto -- protocol (int) - -
-
-
-
-snmp_v3_ctx
- -snmp\_v3\_ctx -- SNMP context (string) - -
-
-
-
-username
- -username -- the username (string) - -
-
-
-
-### _class_ **Value**
-
-This type represents the c-type confd\_value\_t.
-
-The contructor for this type has the following signature:
-
-Value(init, type) -> object
-
-If type is not provided it will be automatically set by inspecting the type of argument init according to this table:
-
-| Python type | Value type |
-| ----------- | ---------- |
-| bool | C\_BOOL |
-| int | C\_INT32 |
-| long | C\_INT64 |
-| float | C\_DOUBLE |
-| string | C\_BUF |
-
-If any other type is provided for the init argument, the type will be set to C\_BUF and the value will be the string representation of init.
-
-For types C\_XMLTAG, C\_XMLBEGIN and C\_XMLEND the init argument must be a 2-tuple which specifies the ns and tag values like this: (ns, tag).
-
-For type C\_IDENTITYREF the init argument must be a 2-tuple which specifies the ns and id values like this: (ns, id).
-
-For types C\_IPV4, C\_IPV6, C\_DATETIME, C\_DATE, C\_TIME, C\_DURATION, C\_OID, C\_IPV4PREFIX and C\_IPV6PREFIX, the init argument must be a string.
-
-For type C\_DECIMAL64 the init argument must be a string, or a 2-tuple which specifies value and fraction digits like this: (value, fraction\_digits).
-
-For type C\_BINARY the init argument must be a bytes instance.
-
-Keyword arguments:
-
-* init -- the initial value
-* type -- type (optional, see confd\_types(3))
-
-Members:
-
-usid
- -usid -- user session id (int) - -
-
-
-
-as_decimal64(...)
- -Method: - -```python -as_decimal64() -> Tuple[int, int] -``` - -Returns a tuple containing (value, fraction\_digits) if this value is of type C\_DECIMAL64. - -
-
-
-
-as_list(...)
- -Method: - -```python -as_list() -> list -``` - -Returns a list of Value's if this value is of type C\_LIST. - -
-
-
-
-as_pyval(...)
- -Method: - -```python -as_pyval() -> Any -``` - -Tries to convert a Value to a native Python type. If possible the object returned will be of the same type as used when initializing a Value object. If the type cannot be represented as something useful in Python a string will be returned. Note that not all Value types are supported. - -E.g. assuming you already have a value object, this should be possible in most cases: - -newvalue = Value(value.as\_pyval(), value.confd\_type()) - -
-
-
-
-as_xmltag(...)
- -Method: - -```python -as_xmltag() -> XmlTag -``` - -Returns a XmlTag instance if this value is of type C\_XMLTAG. - -
-
-
-
-confd_type(...)
- -Method: - -```python -confd_type() -> int -``` - -Returns the confd type. - -
-
-
-
-confd_type_str(...)
- -Method: - -```python -confd_type_str() -> str -``` - -Returns a string representation for the Value type. - -
-
-
-
-str2val(...)
- -Class method: - -```python -str2val(value, schema_type) -> Value -(class method) -``` - -Create and return a Value from a string. The schema\_type argument must be either a 2-tuple with namespace and keypath, a CsNode instance or a CsType instance. - -Keyword arguments: - -* value -- string value -* schema\_type -- either (ns, keypath), a CsNode or a CsType - -
-
-
-
-### _class_ **XmlTag**
-
-This type represent the c-type struct xml\_tag.
-
-The contructor for this type has the following signature:
-
-XmlTag(ns, tag) -> object
-
-Keyword arguments:
-
-* ns -- namespace hash
-* tag -- tag hash
-
-Members:
-
-val2str(...)
- -Method: - -```python -val2str(schema_type) -> str -``` - -Return a string representation of Value. The schema\_type argument must be either a 2-tuple with namespace and keypath, a CsNode instance or a CsType instance. - -Keyword arguments: - -* schema\_type -- either (ns, keypath), a CsNode or a CsType - -
-
-
-
-ns
- -namespace hash value (unsigned int) - -
-
-
-
-## Predefined Values
-
-```python
-
-ACCUMULATE = 1
-ADDR = '127.0.0.1'
-ALREADY_LOCKED = -4
-ATTR_ANNOTATION = 2147483649
-ATTR_BACKPOINTER = 2147483651
-ATTR_INACTIVE = 0
-ATTR_ORIGIN = 2147483655
-ATTR_ORIGINAL_VALUE = 2147483653
-ATTR_OUT_OF_BAND = 2147483664
-ATTR_REFCOUNT = 2147483650
-ATTR_TAGS = 2147483648
-ATTR_WHEN = 2147483652
-CANDIDATE = 1
-CMP_EQ = 1
-CMP_GT = 3
-CMP_GTE = 4
-CMP_LT = 5
-CMP_LTE = 6
-CMP_NEQ = 2
-CMP_NOP = 0
-CONFD_EOF = -2
-CONFD_ERR = -1
-CONFD_OK = 0
-CONFD_PORT = 4565
-CS_NODE_CMP_NORMAL = 0
-CS_NODE_CMP_SNMP = 1
-CS_NODE_CMP_SNMP_IMPLIED = 2
-CS_NODE_CMP_UNSORTED = 4
-CS_NODE_CMP_USER = 3
-CS_NODE_HAS_DISPLAY_WHEN = 1024
-CS_NODE_HAS_META_DATA = 2048
-CS_NODE_HAS_MOUNT_POINT = 32768
-CS_NODE_HAS_WHEN = 512
-CS_NODE_IS_ACTION = 8
-CS_NODE_IS_CASE = 128
-CS_NODE_IS_CDB = 4
-CS_NODE_IS_CONTAINER = 256
-CS_NODE_IS_DYN = 1
-CS_NODE_IS_LEAFREF = 16384
-CS_NODE_IS_LEAF_LIST = 8192
-CS_NODE_IS_LIST = 1
-CS_NODE_IS_NOTIF = 64
-CS_NODE_IS_PARAM = 16
-CS_NODE_IS_RESULT = 32
-CS_NODE_IS_STRING_AS_BINARY = 65536
-CS_NODE_IS_WRITE = 2
-CS_NODE_IS_WRITE_ALL = 4096
-C_BINARY = 39
-C_BIT32 = 29
-C_BIT64 = 30
-C_BITBIG = 50
-C_BOOL = 17
-C_BUF = 5
-C_CDBBEGIN = 37
-C_DATE = 20
-C_DATETIME = 19
-C_DECIMAL64 = 43
-C_DEFAULT = 42
-C_DOUBLE = 14
-C_DQUAD = 46
-C_DURATION = 27
-C_EMPTY = 53
-C_ENUM_HASH = 28
-C_ENUM_VALUE = 28
-C_HEXSTR = 47
-C_IDENTITYREF = 44
-C_INT16 = 7
-C_INT32 = 8
-C_INT64 = 9
-C_INT8 = 6
-C_IPV4 = 15
-C_IPV4PREFIX = 40
-C_IPV4_AND_PLEN = 48
-C_IPV6 = 16
-C_IPV6PREFIX = 41
-C_IPV6_AND_PLEN = 49
-C_LIST = 31
-C_NOEXISTS = 1
-C_OBJECTREF = 34
-C_OID = 38
-C_PTR = 36
-C_QNAME = 18
-C_STR = 4
-C_SYMBOL = 3
-C_TIME = 23
-C_UINT16 = 11
-C_UINT32 = 12
-C_UINT64 = 13
-C_UINT8 = 10
-C_UNION = 35
-C_XMLBEGIN = 32
-C_XMLBEGINDEL = 45
-C_XMLEND = 33
-C_XMLMOVEAFTER = 52
-C_XMLMOVEFIRST = 51
-C_XMLTAG = 2
-DB_INVALID = 0
-DB_VALID = 1
-DEBUG = 1
-DELAYED_RESPONSE = 2
-EOF = -2
-ERR = -1
-ERRCODE_ACCESS_DENIED = 3
-ERRCODE_APPLICATION = 4
-ERRCODE_APPLICATION_INTERNAL = 5
-ERRCODE_DATA_MISSING = 8
-ERRCODE_INCONSISTENT_VALUE = 2
-ERRCODE_INTERNAL = 7
-ERRCODE_INTERRUPT = 9
-ERRCODE_IN_USE = 0
-ERRCODE_PROTO_USAGE = 6
-ERRCODE_RESOURCE_DENIED = 1
-ERRINFO_KEYPATH = 0
-ERRINFO_STRING = 1
-ERR_ABORTED = 49
-ERR_ACCESS_DENIED = 3
-ERR_ALREADY_EXISTS = 2
-ERR_APPLICATION_INTERNAL = 39
-ERR_BADPATH = 8
-ERR_BADSTATE = 17
-ERR_BADTYPE = 5
-ERR_BAD_CONFIG = 36
-ERR_BAD_KEYREF = 14
-ERR_CLI_CMD = 59
-ERR_DATA_MISSING = 58
-ERR_EOF = 45
-ERR_EXTERNAL = 19
-ERR_HA_ABORT = 71
-ERR_HA_BADCONFIG = 69
-ERR_HA_BADFXS = 27
-ERR_HA_BADNAME = 29
-ERR_HA_BADTOKEN = 28
-ERR_HA_BADVSN = 52
-ERR_HA_BIND = 30
-ERR_HA_CLOSED = 26
-ERR_HA_CONNECT = 25
-ERR_HA_NOTICK = 31
-ERR_HA_WITH_UPGRADE = 47
-ERR_INCONSISTENT_VALUE = 38
-ERR_INTERNAL = 18
-ERR_INUSE = 11
-ERR_INVALID_INSTANCE = 43
-ERR_LIB_NOT_INITIALIZED = 34
-ERR_LOCKED = 10
-ERR_MALLOC = 20
-ERR_MISSING_INSTANCE = 42
-ERR_MUST_FAILED = 41
-ERR_NOEXISTS = 1
-ERR_NON_UNIQUE = 13
-ERR_NOSESSION = 22
-ERR_NOSTACK = 9
-ERR_NOTCREATABLE = 6
-ERR_NOTDELETABLE = 7
-ERR_NOTMOVABLE = 46
-ERR_NOTRANS = 61
-ERR_NOTSET = 12
-ERR_NOT_IMPLEMENTED = 51
-ERR_NOT_WRITABLE = 4
-ERR_NO_MOUNT_ID = 67
-ERR_OS = 24
-ERR_POLICY_COMPILATION_FAILED = 54
-ERR_POLICY_EVALUATION_FAILED = 55
-ERR_POLICY_FAILED = 53
-ERR_PROTOUSAGE = 21
-ERR_RESOURCE_DENIED = 37
-ERR_STALE_INSTANCE = 68
-ERR_START_FAILED = 57
-ERR_SUBAGENT_DOWN = 33
-ERR_TIMEOUT = 48
-ERR_TOOMANYTRANS = 23
-ERR_TOO_FEW_ELEMS = 15
-ERR_TOO_MANY_ELEMS = 16
-ERR_TOO_MANY_SESSIONS = 35
-ERR_TRANSACTION_CONFLICT = 70
-ERR_UNAVAILABLE = 44
-ERR_UNSET_CHOICE = 40
-ERR_UPGRADE_IN_PROGRESS = 60
-ERR_VALIDATION_WARNING = 32
-ERR_XPATH = 50
-EXEC_COMPARE = 13
-EXEC_CONTAINS = 11
-EXEC_DERIVED_FROM = 9
-EXEC_DERIVED_FROM_OR_SELF = 10
-EXEC_RE_MATCH = 8
-EXEC_STARTS_WITH = 7
-EXEC_STRING_COMPARE = 12
-FALSE = 0
-FIND_NEXT = 0
-FIND_SAME_OR_NEXT = 1
-HKP_MATCH_FULL = 3
-HKP_MATCH_HKP = 2
-HKP_MATCH_NONE = 0
-HKP_MATCH_TAGS = 1
-INTENDED = 7
-IN_USE = -5
-ITER_CONTINUE = 3
-ITER_RECURSE = 2
-ITER_STOP = 1
-ITER_SUSPEND = 4
-ITER_UP = 5
-ITER_WANT_ANCESTOR_DELETE = 2
-ITER_WANT_ATTR = 4
-ITER_WANT_CLI_ORDER = 1024
-ITER_WANT_CLI_STR = 8
-ITER_WANT_LEAF_FIRST_ORDER = 32
-ITER_WANT_LEAF_LAST_ORDER = 64
-ITER_WANT_PREV = 1
-ITER_WANT_P_CONTAINER = 256
-ITER_WANT_REVERSE = 128
-ITER_WANT_SCHEMA_ORDER = 16
-ITER_WANT_SUPPRESS_OPER_DEFAULTS = 2048
-LF_AND = 1
-LF_CMP = 3
-LF_CMP_LL = 7
-LF_EXEC = 5
-LF_EXISTS = 4
-LF_NOT = 2
-LF_OR = 0
-LF_ORIGIN = 6
-LIB_API_VSN = 134610944
-LIB_API_VSN_STR = '08060000'
-LIB_PROTO_VSN = 86
-LIB_PROTO_VSN_STR = '86'
-LIB_VSN = 134610944
-LIB_VSN_STR = '08060000'
-LISTENER_CLI = 8
-LISTENER_IPC = 1
-LISTENER_NETCONF = 2
-LISTENER_SNMP = 4
-LISTENER_WEBUI = 16
-LOAD_SCHEMA_HASH = 65536
-LOAD_SCHEMA_NODES = 1
-LOAD_SCHEMA_TYPES = 2
-MMAP_SCHEMAS_FIXED_ADDR = 2
-MMAP_SCHEMAS_KEEP_SIZE = 1
-MOP_ATTR_SET = 6
-MOP_CREATED = 1
-MOP_DELETED = 2
-MOP_MODIFIED = 3
-MOP_MOVED_AFTER = 5
-MOP_VALUE_SET = 4
-NCS_ERR_CONNECTION_CLOSED = 64
-NCS_ERR_CONNECTION_REFUSED = 56
-NCS_ERR_CONNECTION_TIMEOUT = 63
-NCS_ERR_DEVICE = 65
-NCS_ERR_SERVICE_CONFLICT = 62
-NCS_ERR_TEMPLATE = 66
-NCS_LISTENER_NETCONF_CALL_HOME = 32
-NCS_PORT = 4569
-NO_DB = 0
-OK = 0
-OPERATIONAL = 4
-PATH = None
-PORT = 4569
-PRE_COMMIT_RUNNING = 6
-PROGRESS_INFO = 3
-PROGRESS_START = 1
-PROGRESS_STOP = 2
-PROTO_CONSOLE = 4
-PROTO_HTTP = 6
-PROTO_HTTPS = 7
-PROTO_SSH = 2
-PROTO_SSL = 5
-PROTO_SYSTEM = 3
-PROTO_TCP = 1
-PROTO_TLS = 9
-PROTO_TRACE = 3
-PROTO_UDP = 8
-PROTO_UNKNOWN = 0
-QUERY_HKEYPATH = 1
-QUERY_HKEYPATH_VALUE = 2
-QUERY_STRING = 0
-QUERY_TAG_VALUE = 3
-READ = 1
-READ_WRITE = 2
-RUNNING = 2
-SERIAL_HKEYPATH = 2
-SERIAL_NONE = 0
-SERIAL_TAG_VALUE = 3
-SERIAL_VALUE_T = 1
-SILENT = 0
-SNMP_COL_ROW = 3
-SNMP_Counter32 = 6
-SNMP_Counter64 = 9
-SNMP_INTEGER = 1
-SNMP_Interger32 = 2
-SNMP_IpAddress = 5
-SNMP_NULL = 0
-SNMP_OBJECT_IDENTIFIER = 4
-SNMP_OCTET_STRING = 3
-SNMP_OID = 2
-SNMP_Opaque = 8
-SNMP_TimeTicks = 7
-SNMP_Unsigned32 = 10
-SNMP_VARIABLE = 1
-STARTUP = 3
-TIMEZONE_UNDEF = -111
-TRACE = 2
-TRANSACTION = 5
-TRANS_CB_FLAG_FILTERED = 1
-TRUE = 1
-USESS_FLAG_FORWARD = 1
-USESS_FLAG_HAS_IDENTIFICATION = 2
-USESS_FLAG_HAS_OPAQUE = 4
-USESS_LOCK_MODE_EXCLUSIVE = 2
-USESS_LOCK_MODE_NONE = 0
-USESS_LOCK_MODE_PRIVATE = 1
-USESS_LOCK_MODE_SHARED = 3
-VALIDATION_FLAG_COMMIT = 2
-VALIDATION_FLAG_TEST = 1
-VALIDATION_WARN = -3
-VERBOSITY_DEBUG = 3
-VERBOSITY_NORMAL = 0
-VERBOSITY_VERBOSE = 1
-VERBOSITY_VERY_VERBOSE = 2
-```
diff --git a/developer-reference/pyapi/modules.lst b/developer-reference/pyapi/modules.lst
deleted file mode 100644
index 321ef797..00000000
--- a/developer-reference/pyapi/modules.lst
+++ /dev/null
@@ -1,20 +0,0 @@
-ncs
-ncs.alarm
-ncs.application
-ncs.cdb
-ncs.dp
-ncs.experimental
-ncs.log
-ncs.maagic
-ncs.maapi
-ncs.progress
-ncs.service_log
-ncs.template
-ncs.util
-_ncs
-_ncs.cdb
-_ncs.dp
-_ncs.error
-_ncs.events
-_ncs.ha
-_ncs.maapi
diff --git a/developer-reference/pyapi/ncs.alarm.md b/developer-reference/pyapi/ncs.alarm.md
deleted file mode 100644
index b41a350c..00000000
--- a/developer-reference/pyapi/ncs.alarm.md
+++ /dev/null
@@ -1,235 +0,0 @@
-# Python ncs.alarm Module
-
-NCS Alarm Manager module.
-
-## Functions
-
-### clear_alarm
-
-```python
-clear_alarm(alarm)
-```
-
-Clear an alarm.
-
-Arguments:
- alarm -- An instance of Alarm.
-
-### managed_object_instance
-
-```python
-managed_object_instance(instanceval)
-```
-
-Create a managed object of type instance-identifier.
-
-Arguments:
- instanceval -- The instance-identifier (string or HKeypathRef)
-
-### managed_object_oid
-
-```python
-managed_object_oid(oidval)
-```
-
-Create a managed object of type yang:object-identifier.
-
-Arguments:
- oidval -- The OID (string)
-
-### managed_object_string
-
-```python
-managed_object_string(strval)
-```
-
-Create a managed object of type string.
-
-Arguments:
- strval --- The string value
-
-### raise_alarm
-
-```python
-raise_alarm(alarm)
-```
-
-Raise an alarm.
-
-Arguments:
- alarm -- An instance of Alarm.
-
-
-## Classes
-
-### _class_ **Alarm**
-
-Class representing an alarm.
-
-```python
-Alarm(managed_device, managed_object, alarm_type, specific_problem, severity, alarm_text, impacted_objects=None, related_alarms=None, root_cause_objects=None, time_stamp=None, custom_attributes=None)
-```
-
-Create an Alarm object.
-
-Arguments:
-managed_device
- The managed device this alarm is associated with. Plain string
- which identifies the device.
-managed_object
- The managed object this alarm is associated with. Also referred
- to as the "Alarming Object". This object may not be referred to
- in the root_cause_objects parameter. If an NCS Service
- generates an alarm based on an error state in a device used by
- that service, managed_object should be the service Id and the
- device should be included in the root_cause_objects list. This
- parameter must be a ncs.Value object. Use one of the methods
- managed_object_string(), managed_object_oid() or
- managed_object_instance() to create the value.
-alarm_type
- Type of alarm. This is a YANG identity. Alarm types are defined
- by the YANG developer and should be designed to be as specific
- as possible.
-specific_problem
- If the alarm_type isn't enough to describe the alarm, this
- field can be used in combination. Keep in mind that when
- dynamically adding a specific problem, there is no way for the
- operator to know in advance which alarms can be raised.
-severity
- State of the alarm; cleared, indeterminate, critical, major,
- minor, warning (enum).
-alarm_text
- A human readable description of this problem.
-impacted_objects
- A list of Managed Objects that may no longer function due to
- this alarm. Typically these point to NCS Services that are
- dependent on the objects on the device that reported the
- problem. In NCS 2.3 and later there is a backpointer attribute
- available on objects in the device tree that has been created by
- a Service. These backpointers are instance reference pointers
- that should be set in this list. Use one of the methods
- managed_object_string(), managed_object_oid() or
- managed_object_instance() to create the instances to populate
- this list.
-related_alarms
- References to other alarms that have been generated as a
- consequence of this alarm, or that has some other relationship
- to this alarm. Should be a list of AlarmId instances.
-root_cause_objects
- A list of Managed Objects that are likely to be the root cause
- of this alarm. This is different from the "Alarming Object". See
- managed_object above for details. Use one of the methods
- managed_object_string(), managed_object_oid() or
- managed_object_instance() to create the instances to populate
- this list.
-time_stamp
- A date-and-time when this alarm was generated.
-custom_attributes
- A list of custom leafs augmented into the alarm list.
-
-Members:
-
-tag
- -tag hash value (unsigned int) - -
-
-
-
-add_attribute(...)
- -Method: - -```python -add_attribute(self, prefix, tag, value) -``` - -Add or update custom attribute - -
-
-
-
-add_status_attribute(...)
- -Method: - -```python -add_status_attribute(self, prefix, tag, value) -``` - -Add or update custom status change attribute - -
-
-
-
-alarm_id(...)
- -Method: - -```python -alarm_id(self) -``` - -Get the unique Id of this alarm as an AlarmId instance. - -
-
-
-
-get_key(...)
- -Method: - -```python -get_key(self) -``` - -Get alarm list key. - -
-
-
-
-### _class_ **AlarmId**
-
-Represents the unique Id of an Alarm.
-
-```python
-AlarmId(alarm_type, managed_device, managed_object, specific_problem=None)
-```
-
-Create an AlarmId.
-
-Members:
-
-_None_
-
-### _class_ **CustomAttribute**
-
-Class representing a custom attribute set on an alarm.
-
-```python
-CustomAttribute(prefix, tag, value)
-```
-
-Members:
-
-_None_
-
-### _class_ **CustomStatusAttribute**
-
-Class representing a custom attribute set on an alarm.
-
-```python
-CustomStatusAttribute(prefix, tag, value)
-```
-
-Members:
-
-_None_
-
diff --git a/developer-reference/pyapi/ncs.application.md b/developer-reference/pyapi/ncs.application.md
deleted file mode 100644
index d6e721f7..00000000
--- a/developer-reference/pyapi/ncs.application.md
+++ /dev/null
@@ -1,896 +0,0 @@
-# Python ncs.application Module
-
-Module for building NCS applications.
-
-## Functions
-
-### get_device
-
-```python
-get_device(node, name)
-```
-
-Get a device node by name.
-
-Returns a maagic node representing a device.
-
-Arguments:
-
-* node -- any maagic node with a Transaction backend or a Transaction object
-* name -- the device name (string)
-
-Returns:
-
-* device node (maagic.Node)
-
-### get_ned_id
-
-```python
-get_ned_id(device)
-```
-
-Get the ned-id of a device.
-
-Returns the ned-id as a string or None if not found.
-
-Arguments:
-
-* device -- a maagic node representing the device (maagic.Node)
-
-Returns:
-
-* ned_id (str)
-
-
-## Classes
-
-### _class_ **Application**
-
-Class for easy implementation of an NCS application.
-
-This class is intended to be sub-classed and used as a 'component class'
-inside an NCS package. It will be instantiated by NCS when the package
-is loaded. The setup() method should to be implemented to register
-service- and action callbacks. When NCS stops or an error occurs,
-teardown() will be called. A 'log' attribute is available for logging.
-
-Example application:
-
- from ncs.application import Application, Service, NanoService
- from ncs.dp import Action, ValidationPoint
-
- class FooService(Service):
- @Service.create
- def cb_create(self, tctx, root, service, proplist):
- # service code here
-
- class FooNanoService(NanoService):
- @NanoService.create
- def cb_nano_create(self, tctx, root, service, plan, component,
- state, proplist, compproplist):
- # service code here
-
- class FooAction(Action):
- @Action.action
- def cb_action(self, uinfo, name, kp, input, output):
- # action code here
-
- class FooValidation(ValidationPoint):
- @ValidationPoint.validate
- def cb_validate(self, tctx, keypath, value, validationpoint):
- # validation code here
-
- class MyApp(Application):
- def setup(self):
- self.log.debug('MyApp start')
- self.register_service('myservice-1', FooService)
- self.register_service('myservice-2', FooService, 'init_arg')
- self.register_nano_service('nano-1', 'myserv:router',
- 'myserv:ntp-initialized',
- FooNanoService)
- self.register_action('action-1', FooAction)
- self.register_validation('validation-1', FooValidation)
-
- def teardown(self):
- self.log.debug('MyApp finish')
-
-```python
-Application(*args, **kwds)
-```
-
-Initialize an Application object.
-
-Not designed to be instantiated directly; these objects are created
-by NCS.
-
-Members:
-
-key
- -_Readonly property_ - -Get alarm list key. - -
-
-
-
-APP_WORKER_STOP_TIMEOUT_S
- -```python -APP_WORKER_STOP_TIMEOUT_S = 1 -``` - - -
-
-
-
-add_running_thread(...)
- -Method: - -```python -add_running_thread(self, class_name) -``` - - -
-
-
-
-create_daemon(...)
- -Method: - -```python -create_daemon(self, name=None) -``` - -Name the underlying dp.Daemon object (deprecated) - -
-
-
-
-critical(...)
- -Method: - -```python -critical(self, line) -``` - - -
-
-
-
-debug(...)
- -Method: - -```python -debug(self, line) -``` - - -
-
-
-
-del_running_thread(...)
- -Method: - -```python -del_running_thread(self, class_name) -``` - - -
-
-
-
-error(...)
- -Method: - -```python -error(self, line) -``` - - -
-
-
-
-exception(...)
- -Method: - -```python -exception(self, line) -``` - - -
-
-
-
-info(...)
- -Method: - -```python -info(self, line) -``` - - -
-
-
-
-reg_finish(...)
- -Method: - -```python -reg_finish(self, cbfun) -``` - - -
-
-
-
-register_action(...)
- -Method: - -```python -register_action(self, actionpoint, action_cls, init_args=None) -``` - -Register an action callback class. - -Call this method to register 'action_cls' as the action callback -class for action point 'actionpoint'. 'action_cls' should be a -subclass of dp.Action. If the optional argument 'init_args' is -supplied it will be passed in to the init() method of the subclass. - -Arguments: - -* actionpoint -- actionpoint (str) -* action_cls -- action callback class -* init_args -- initial arguments (optional) - -
-
-
-
-register_fun(...)
- -Method: - -```python -register_fun(self, start_fun, stop_fun) -``` - -Register custom start and stop functions. - -Call this method to register a start and stop function that -will be called with a dp.Daemon.State during application -setup. - -Example start and stop functions: - - def my_start_fun(state): - state.log.info('my_start_fun START') - return (state, time.time()) - - def my_stop_fun(fun_data): - (state, start_time) = fun_data - state.log.info('my_start_fun started {}'.format(start_time)) - state.log.info('my_start_fun STOP') - -Arguments: - -* start_fun -- start function (fun) -* stop_fun -- stop function (fun) - -
-
-
-
-register_nano_service(...)
- -Method: - -```python -register_nano_service(self, servicepoint, componenttype, state, nano_service_cls, init_args=None) -``` - -Register a nano service callback class. - -Call this method to register 'nano_service_cls' as the nano service -callback class for service point 'servicepoint'. -'nano service_cls' should be a subclass of NanoService. -If the optional argument 'init_args' is supplied -it will be passed in to the init() method of the subclass. - -Arguments: - -* servicepoint -- servicepoint (str) -* componenttype -- nano plan component(str) -* state -- nano plan state (str) -* service_cls -- service callback class -* init_args -- initial arguments (optional) - -
-
-
-
-register_service(...)
- -Method: - -```python -register_service(self, servicepoint, service_cls, init_args=None) -``` - -Register a service callback class. - -Call this method to register 'service_cls' as the service callback -class for service point 'servicepoint'. 'service_cls' should be a -subclass of Service. If the optional argument 'init_args' is supplied -it will be passed in to the init() method of the subclass. - -Arguments: - -* servicepoint -- servicepoint (str) -* service_cls -- service callback class -* init_args -- initial arguments (optional) - -
-
-
-
-register_trans_cb(...)
- -Method: - -```python -register_trans_cb(self, trans_cb_cls) -``` - -Register a transaction callback class. - -If a custom transaction callback implementation is needed, call this -method with the transaction callback class as the 'trans_cb_cls' -argument. - -Arguments: - -* trans_cb_cls -- transaction callback class - -
-
-
-
-register_validation(...)
- -Method: - -```python -register_validation(self, validationpoint, validation_cls, init_args=None) -``` - -Register a validation callback class. - -Call this method to register 'validation_cls' as the -validation callback class for validation point -'validationpoint'. 'validation_cls' should be a subclass of -ValidationPoint. If the optional argument 'init_args' is -supplied it will be passed in to the init() method of the -subclass. - -Arguments: - -* validationpoint -- validationpoint (str) -* validation_cls -- validation callback class -* init_args -- initial arguments (optional) - -
-
-
-
-set_log_level(...)
- -Method: - -```python -set_log_level(self, log_level) -``` - -Set log level for all workers (only relevant for -_ProcessAppWorker) - -Arguments: - -* log_level -- logging level, using logging.Logger (int) - -
-
-
-
-set_self_assign_warning(...)
- -Method: - -```python -set_self_assign_warning(self, warning) -``` - -Set self assign warning for all workers. - -Arguments: - -* warning -- warning type (alarm, log, off). (string) - -
-
-
-
-setup(...)
- -Method: - -```python -setup(self) -``` - -Application setup method. - -Override this method to register actions and services. Any other -initialization could also be done here. If the call to this method -throws an exception the teardown method will be immediately called -and the application shutdown. - -
-
-
-
-teardown(...)
- -Method: - -```python -teardown(self) -``` - -Application teardown method. - -Override this method to clean up custom resources allocated in -setup(). - -
-
-
-
-unreg_finish(...)
- -Method: - -```python -unreg_finish(self, cbfun) -``` - - -
-
-
-
-### _class_ **NanoService**
-
-NanoService callback.
-
-This class makes it easy to create and register nano service callbacks by
-subclassing it and implementing some of the nano service callbacks.
-
-```python
-NanoService(daemon, servicepoint, componenttype, state, log=None, init_args=None)
-```
-
-Initialize this object.
-
-The 'daemon' argument should be a Daemon instance. 'servicepoint'
-is the name of the tailf:servicepoint to manage. Argument 'log' can
-be any log object, and if not set the Daemon log will be used.
-'init_args' may be any object that will be passed into init() when
-this object is constructed. Lastly, the low-level function
-dp.register_nano_service_cb() will be called.
-
-When creating a service callback using Application.register_nano_service
-there is no need to manually initialize this object as it is then
-done automatically.
-
-Members:
-
-warning(...)
- -Method: - -```python -warning(self, line) -``` - - -
-
-
-
-create(...)
- -Static method: - -```python -create(fn) -``` - -Decorator for the cb_nano_create callback. - -Using this decorator alters the signature of the cb_create callback -and passes in maagic.Node objects for root and service. -The maagic.Node objects received in 'root' and 'service' are backed -by a MAAPI connection with the FASTMAP handle attached. To update -'proplist' simply return it from this function. - -Example of a decorated cb_create: - - @NanoService.create - def cb_nano_create(self, tctx, root, - service, plan, component, state, - proplist, compproplist): - pass - -Callback arguments: - -* tctx - transaction context (TransCtxRef) -* root -- root node (maagic.Node) -* service -- service node (maagic.Node) -* plan -- current plan node (maagic.Node) -* component -- plan component active for this invokation -* state -- plan component state active for this invokation -* proplist - properties (list(tuple(str, str))) -* compproplist - component properties (list(tuple(str, str))) - -
-
-
-
-delete(...)
- -Static method: - -```python -delete(fn) -``` - -Decorator for the cb_nano_delete callback. - -Using this decorator alters the signature of the cb_delete callback -and passes in maagic.Node objects for root and service. -The maagic.Node objects received in 'root' and 'service' are backed -by a MAAPI connection with the FASTMAP handle attached. To update -'proplist' simply return it from this function. - -Example of a decorated cb_create: - - @NanoService.delete - def cb_nano_delete(self, tctx, root, - service, plan, component, state, - proplist, compproplist): - pass - -Callback arguments: - -* tctx - transaction context (TransCtxRef) -* root -- root node (maagic.Node) -* service -- service node (maagic.Node) -* plan -- current plan node (maagic.Node) -* component -- plan component active for this invokation -* state -- plan component state active for this invokation -* proplist - properties (list(tuple(str, str))) -* compproplist - component properties (list(tuple(str, str))) - -
-
-
-
-init(...)
- -Method: - -```python -init(self, init_args) -``` - -Custom initialization. - -When registering a service using Application this method will be -called with the 'init_args' passed into the register_service() -function. - -
-
-
-
-maapi
- -_Readonly property_ - - -
-
-
-
-start(...)
- -Method: - -```python -start(self) -``` - -Start NanoService - -
-
-
-
-### _class_ **PlanComponent**
-
-Service plan component.
-
-The usage of this class is in conjunction with a service that
-uses a reactive FASTMAP pattern.
-With a plan the service states can be tracked and controlled.
-
-A service plan can consist of many PlanComponent's.
-This is operational data that is stored together with the service
-configuration.
-
-```python
-PlanComponent(planpath, name, component_type)
-```
-
-Initialize a PlanComponent.
-
-Members:
-
-stop(...)
- -Method: - -```python -stop(self) -``` - -Stop NanoService - -
-
-
-
-append_state(...)
- -Method: - -```python -append_state(self, state_name) -``` - -Append a new state to this plan component. - -The state status will be initialized to 'ncs:not-reached'. - -
-
-
-
-set_failed(...)
- -Method: - -```python -set_failed(self, state_name) -``` - -Set state status to 'ncs:failed'. - -
-
-
-
-set_reached(...)
- -Method: - -```python -set_reached(self, state_name) -``` - -Set state status to 'ncs:reached'. - -
-
-
-
-### _class_ **Service**
-
-Service callback.
-
-This class makes it easy to create and register service callbacks by
-subclassing it and implementing some of the service callbacks.
-
-```python
-Service(daemon, servicepoint, log=None, init_args=None)
-```
-
-Initialize this object.
-
-The 'daemon' argument should be a Daemon instance. 'servicepoint'
-is the name of the tailf:servicepoint to manage. Argument 'log' can
-be any log object, and if not set the Daemon log will be used.
-'init_args' may be any object that will be passed into init() when
-this object is constructed. Lastly, the low-level function
-dp.register_service_cb() will be called.
-
-When creating a service callback using Application.register_service
-there is no need to manually initialize this object as it is then
-done automatically.
-
-Members:
-
-set_status(...)
- -Method: - -```python -set_status(self, state_name, status) -``` - -Set state status. - -
-
-
-
-create(...)
- -Static method: - -```python -create(fn) -``` - -Decorator for the cb_create callback. - -Using this decorator alters the signature of the cb_create callback -and passes in maagic.Node objects for root and service. -The maagic.Node objects received in 'root' and 'service' are backed -by a MAAPI connection with the FASTMAP handle attached. To update -'proplist' simply return it from this function. - -Example of a decorated cb_create: - - @Service.create - def cb_create(self, tctx, root, service, proplist): - pass - -Callback arguments: - -* tctx - transaction context (TransCtxRef) -* root -- root node (maagic.Node) -* service -- service node (maagic.Node) -* proplist - properties (list(tuple(str, str))) - -
-
-
-
-init(...)
- -Method: - -```python -init(self, init_args) -``` - -Custom initialization. - -When registering a service using Application this method will be -called with the 'init_args' passed into the register_service() -function. - -
-
-
-
-maapi
- -_Readonly property_ - - -
-
-
-
-post_modification(...)
- -Static method: - -```python -post_modification(fn) -``` - -Decorator for the cb_post_modification callback. - -For details see Service.pre_modification decorator. - -
-
-
-
-pre_modification(...)
- -Static method: - -```python -pre_modification(fn) -``` - -Decorator for the cb_pre_modification callback. - -Using this decorator alters the signature of the cb_pre_modification. -callback and passes in a maagic.Node object for root. -This method is invoked outside FASTMAP. To update 'proplist' simply -return it from this function. - -Example of a decorated cb_pre_modification: - - @Service.pre_modification - def cb_pre_modification(self, tctx, op, kp, root, proplist): - pass - -Callback arguments: - -* tctx - transaction context (TransCtxRef) -* op -- operation (int) -* kp -- keypath (HKeypathRef) -* root -- root node (maagic.Node) -* proplist - properties (list(tuple(str, str))) - -
-
-
-
-start(...)
- -Method: - -```python -start(self) -``` - -Start Service - -
-
-
-
diff --git a/developer-reference/pyapi/ncs.cdb.md b/developer-reference/pyapi/ncs.cdb.md
deleted file mode 100644
index 22c241a2..00000000
--- a/developer-reference/pyapi/ncs.cdb.md
+++ /dev/null
@@ -1,1000 +0,0 @@
-# Python ncs.cdb Module
-
-CDB high level module.
-
-This module implements a couple of classes for subscribing
-to CDB events.
-
-## Classes
-
-### _class_ **OperSubscriber**
-
-CDB Subscriber for oper data.
-
-Use this class when subscribing on operational data. In all other means
-the behavior is the same as for Subscriber().
-
-```python
-OperSubscriber(app=None, log=None, host='127.0.0.1', port=4569, path=None)
-```
-
-Initialize an OperSubscriber.
-
-Members:
-
-stop(...)
- -Method: - -```python -stop(self) -``` - -Stop Service - -
-
-
-
-daemon
- -A boolean value indicating whether this thread is a daemon thread. - -This must be set before start() is called, otherwise RuntimeError is -raised. Its initial value is inherited from the creating thread; the -main thread is not a daemon thread and therefore all threads created in -the main thread default to daemon = False. - -The entire Python program exits when only daemon threads are left. - -
-
-
-
-getName(...)
- -Method: - -```python -getName(self) -``` - -Return a string used for identification purposes only. - -This method is deprecated, use the name attribute instead. - -
-
-
-
-ident
- -_Readonly property_ - -Thread identifier of this thread or None if it has not been started. - -This is a nonzero integer. See the get_ident() function. Thread -identifiers may be recycled when a thread exits and another thread is -created. The identifier is available even after the thread has exited. - -
-
-
-
-init(...)
- -Method: - -```python -init(self) -``` - -Custom initialization. - -Override this method to do custom initialization without needing -to override __init__. - -
-
-
-
-isDaemon(...)
- -Method: - -```python -isDaemon(self) -``` - -Return whether this thread is a daemon. - -This method is deprecated, use the daemon attribute instead. - -
-
-
-
-is_alive(...)
- -Method: - -```python -is_alive(self) -``` - -Return whether the thread is alive. - -This method returns True just before the run() method starts until just -after the run() method terminates. See also the module function -enumerate(). - -
-
-
-
-join(...)
- -Method: - -```python -join(self, timeout=None) -``` - -Wait until the thread terminates. - -This blocks the calling thread until the thread whose join() method is -called terminates -- either normally or through an unhandled exception -or until the optional timeout occurs. - -When the timeout argument is present and not None, it should be a -floating point number specifying a timeout for the operation in seconds -(or fractions thereof). As join() always returns None, you must call -is_alive() after join() to decide whether a timeout happened -- if the -thread is still alive, the join() call timed out. - -When the timeout argument is not present or None, the operation will -block until the thread terminates. - -A thread can be join()ed many times. - -join() raises a RuntimeError if an attempt is made to join the current -thread as that would cause a deadlock. It is also an error to join() a -thread before it has been started and attempts to do so raises the same -exception. - -
-
-
-
-name
- -A string used for identification purposes only. - -It has no semantics. Multiple threads may be given the same name. The -initial name is set by the constructor. - -
-
-
-
-native_id
- -_Readonly property_ - -Native integral thread ID of this thread, or None if it has not been started. - -This is a non-negative integer. See the get_native_id() function. -This represents the Thread ID as reported by the kernel. - -
-
-
-
-register(...)
- -Method: - -```python -register(self, path, iter_obj=None, iter_flags=1, priority=0, flags=0, subtype=None) -``` - -Register an iterator object at a specific path. - -Setting 'iter_obj' to None will internally use 'self' as the iterator -object which means that Subscriber needs to be sub-classed. - -Operational and configuration subscriptions can be done on the -same Subscriber, but in that case the notifications may be -arbitrarily interleaved, including operational notifications -arriving between different configuration notifications for the -same transaction. If this is a problem, use separate -Subscriber instances for operational and configuration -subscriptions. - -Arguments: - -* path -- path to node (str) -* iter_object -- iterator object (obj, optional) -* iter_flags -- iterator flags (int, optional) -* priority -- priority order for subscribers (int) -* flags -- additional subscriber flags (int) -* subtype -- subscriber type SUB_RUNNING, SUB_RUNNING_TWOPHASE, - SUB_OPERATIONAL (cdb) - -Returns: - -* subscription point (int) - -Flags (cdb): - -* SUB_WANT_ABORT_ON_ABORT - -Iterator Flags (ncs): - -* ITER_WANT_PREV -* ITER_WANT_ANCESTOR_DELETE -* ITER_WANT_ATTR -* ITER_WANT_CLI_STR -* ITER_WANT_SCHEMA_ORDER -* ITER_WANT_LEAF_FIRST_ORDER -* ITER_WANT_LEAF_LAST_ORDER -* ITER_WANT_REVERSE -* ITER_WANT_P_CONTAINER -* ITER_WANT_CLI_ORDER - -
-
-
-
-run(...)
- -Method: - -```python -run(self) -``` - -Main processing loop. - -
-
-
-
-setDaemon(...)
- -Method: - -```python -setDaemon(self, daemonic) -``` - -Set whether this thread is a daemon. - -This method is deprecated, use the .daemon property instead. - -
-
-
-
-setName(...)
- -Method: - -```python -setName(self, name) -``` - -Set the name string for this thread. - -This method is deprecated, use the name attribute instead. - -
-
-
-
-start(...)
- -Method: - -```python -start(self) -``` - -Start the subscriber. - -
-
-
-
-### _class_ **Subscriber**
-
-CDB Subscriber for config data.
-
-Supports the pattern of collecting changes and then handle the changes in
-a separate thread. For each subscription point a handler object must be
-registered. The following methods will be called on the handler:
-
-* pre_iterate() (optional)
-
- Called just before iteration starts, may return a state object
- which will be passed on to the iterate method. If not implemented,
- the state object will be None.
-
-* iterate(kp, op, oldv, newv, state) (mandatory)
-
- Called for each change in the change set.
-
-* post_iterate(state) (optional)
-
- Runs in a separate thread once iteration has finished and the
- subscription socket has been synced. Will receive the final state
- object from iterate() as an argument.
-
-* should_iterate() (optional)
-
- Called to check if the subscriber wants to iterate. If this method
- returns False, neither pre_iterate() nor iterate() will be called.
- Can e.g. be used by HA secondary nodes to skip iteration. If not
- implemented, pre_iterate() and iterate() will always be called.
-
-* should_post_iterate(state) (optional)
-
- Called to determine whether post_iterate() should be called
- or not. It is recommended to implement this method to prevent
- the subscriber from calling post_iterate() when not needed.
- Should return True if post_iterate() should run, otherwise False.
- If not implemented, post_iterate() will always be called.
-
-Example iterator object:
-
- class MyIter(object):
- def pre_iterate(self):
- return []
-
- def iterate(self, kp, op, oldv, newv, state):
- if op is ncs.MOP_VALUE_SET:
- state.append(newv)
- return ncs.ITER_RECURSE
-
- def post_iterate(self, state):
- for item in state:
- print(item)
-
- def should_post_iterate(self, state):
- return state != []
-
-The same handler may be registered for multiple subscription points.
-In that case, pre_iterate() will only be called once, followed by iterate
-calls for all subscription points, and finally a single call to
-post_iterate().
-
-```python
-Subscriber(app=None, log=None, host='127.0.0.1', port=4569, subtype=1, name='', path=None)
-```
-
-Initialize a Subscriber.
-
-Members:
-
-stop(...)
- -Method: - -```python -stop(self) -``` - -Stop the subscriber. - -
-
-
-
-daemon
- -A boolean value indicating whether this thread is a daemon thread. - -This must be set before start() is called, otherwise RuntimeError is -raised. Its initial value is inherited from the creating thread; the -main thread is not a daemon thread and therefore all threads created in -the main thread default to daemon = False. - -The entire Python program exits when only daemon threads are left. - -
-
-
-
-getName(...)
- -Method: - -```python -getName(self) -``` - -Return a string used for identification purposes only. - -This method is deprecated, use the name attribute instead. - -
-
-
-
-ident
- -_Readonly property_ - -Thread identifier of this thread or None if it has not been started. - -This is a nonzero integer. See the get_ident() function. Thread -identifiers may be recycled when a thread exits and another thread is -created. The identifier is available even after the thread has exited. - -
-
-
-
-init(...)
- -Method: - -```python -init(self) -``` - -Custom initialization. - -Override this method to do custom initialization without needing -to override __init__. - -
-
-
-
-isDaemon(...)
- -Method: - -```python -isDaemon(self) -``` - -Return whether this thread is a daemon. - -This method is deprecated, use the daemon attribute instead. - -
-
-
-
-is_alive(...)
- -Method: - -```python -is_alive(self) -``` - -Return whether the thread is alive. - -This method returns True just before the run() method starts until just -after the run() method terminates. See also the module function -enumerate(). - -
-
-
-
-join(...)
- -Method: - -```python -join(self, timeout=None) -``` - -Wait until the thread terminates. - -This blocks the calling thread until the thread whose join() method is -called terminates -- either normally or through an unhandled exception -or until the optional timeout occurs. - -When the timeout argument is present and not None, it should be a -floating point number specifying a timeout for the operation in seconds -(or fractions thereof). As join() always returns None, you must call -is_alive() after join() to decide whether a timeout happened -- if the -thread is still alive, the join() call timed out. - -When the timeout argument is not present or None, the operation will -block until the thread terminates. - -A thread can be join()ed many times. - -join() raises a RuntimeError if an attempt is made to join the current -thread as that would cause a deadlock. It is also an error to join() a -thread before it has been started and attempts to do so raises the same -exception. - -
-
-
-
-name
- -A string used for identification purposes only. - -It has no semantics. Multiple threads may be given the same name. The -initial name is set by the constructor. - -
-
-
-
-native_id
- -_Readonly property_ - -Native integral thread ID of this thread, or None if it has not been started. - -This is a non-negative integer. See the get_native_id() function. -This represents the Thread ID as reported by the kernel. - -
-
-
-
-register(...)
- -Method: - -```python -register(self, path, iter_obj=None, iter_flags=1, priority=0, flags=0, subtype=None) -``` - -Register an iterator object at a specific path. - -Setting 'iter_obj' to None will internally use 'self' as the iterator -object which means that Subscriber needs to be sub-classed. - -Operational and configuration subscriptions can be done on the -same Subscriber, but in that case the notifications may be -arbitrarily interleaved, including operational notifications -arriving between different configuration notifications for the -same transaction. If this is a problem, use separate -Subscriber instances for operational and configuration -subscriptions. - -Arguments: - -* path -- path to node (str) -* iter_object -- iterator object (obj, optional) -* iter_flags -- iterator flags (int, optional) -* priority -- priority order for subscribers (int) -* flags -- additional subscriber flags (int) -* subtype -- subscriber type SUB_RUNNING, SUB_RUNNING_TWOPHASE, - SUB_OPERATIONAL (cdb) - -Returns: - -* subscription point (int) - -Flags (cdb): - -* SUB_WANT_ABORT_ON_ABORT - -Iterator Flags (ncs): - -* ITER_WANT_PREV -* ITER_WANT_ANCESTOR_DELETE -* ITER_WANT_ATTR -* ITER_WANT_CLI_STR -* ITER_WANT_SCHEMA_ORDER -* ITER_WANT_LEAF_FIRST_ORDER -* ITER_WANT_LEAF_LAST_ORDER -* ITER_WANT_REVERSE -* ITER_WANT_P_CONTAINER -* ITER_WANT_CLI_ORDER - -
-
-
-
-run(...)
- -Method: - -```python -run(self) -``` - -Main processing loop. - -
-
-
-
-setDaemon(...)
- -Method: - -```python -setDaemon(self, daemonic) -``` - -Set whether this thread is a daemon. - -This method is deprecated, use the .daemon property instead. - -
-
-
-
-setName(...)
- -Method: - -```python -setName(self, name) -``` - -Set the name string for this thread. - -This method is deprecated, use the name attribute instead. - -
-
-
-
-start(...)
- -Method: - -```python -start(self) -``` - -Start the subscriber. - -
-
-
-
-### _class_ **TwoPhaseSubscriber**
-
-CDB Subscriber for config data with support for aborting transactions.
-
-Subscriber that is capable of aborting transactions during the
-prepare phase of a transaction.
-
-The following methods will be called on the handler in addition to
-the methods described in Subscriber:
-
-* prepare(kp, op, oldv, newv, state) (mandatory)
-
- Called in the transaction prepare phase. If an exception occurs
- during the invocation of prepare the transaction is aborted.
-
-* cleanup(state) (optional)
-
- Called after a prepare failure if available. Use to cleanup
- resources allocated by prepare.
-
-* abort(kp, op, oldv, newv, state) (mandatory)
-
- Called if another subscriber aborts the transaction and this
- transaction has been prepared.
-
-Methods are called in the following order:
-
-1. should_iterate -> pre_iterate ( -> cleanup, on exception)
-2. should_iterate -> iterate -> post_iterate
-3. should_iterate -> abort, if transaction is aborted by other subscriber
-
-```python
-TwoPhaseSubscriber(name, app=None, log=None, host='127.0.0.1', port=4569, path=None)
-```
-
-Members:
-
-stop(...)
- -Method: - -```python -stop(self) -``` - -Stop the subscriber. - -
-
-
-
-daemon
- -A boolean value indicating whether this thread is a daemon thread. - -This must be set before start() is called, otherwise RuntimeError is -raised. Its initial value is inherited from the creating thread; the -main thread is not a daemon thread and therefore all threads created in -the main thread default to daemon = False. - -The entire Python program exits when only daemon threads are left. - -
-
-
-
-getName(...)
- -Method: - -```python -getName(self) -``` - -Return a string used for identification purposes only. - -This method is deprecated, use the name attribute instead. - -
-
-
-
-ident
- -_Readonly property_ - -Thread identifier of this thread or None if it has not been started. - -This is a nonzero integer. See the get_ident() function. Thread -identifiers may be recycled when a thread exits and another thread is -created. The identifier is available even after the thread has exited. - -
-
-
-
-init(...)
- -Method: - -```python -init(self) -``` - -Custom initialization. - -Override this method to do custom initialization without needing -to override __init__. - -
-
-
-
-isDaemon(...)
- -Method: - -```python -isDaemon(self) -``` - -Return whether this thread is a daemon. - -This method is deprecated, use the daemon attribute instead. - -
-
-
-
-is_alive(...)
- -Method: - -```python -is_alive(self) -``` - -Return whether the thread is alive. - -This method returns True just before the run() method starts until just -after the run() method terminates. See also the module function -enumerate(). - -
-
-
-
-join(...)
- -Method: - -```python -join(self, timeout=None) -``` - -Wait until the thread terminates. - -This blocks the calling thread until the thread whose join() method is -called terminates -- either normally or through an unhandled exception -or until the optional timeout occurs. - -When the timeout argument is present and not None, it should be a -floating point number specifying a timeout for the operation in seconds -(or fractions thereof). As join() always returns None, you must call -is_alive() after join() to decide whether a timeout happened -- if the -thread is still alive, the join() call timed out. - -When the timeout argument is not present or None, the operation will -block until the thread terminates. - -A thread can be join()ed many times. - -join() raises a RuntimeError if an attempt is made to join the current -thread as that would cause a deadlock. It is also an error to join() a -thread before it has been started and attempts to do so raises the same -exception. - -
-
-
-
-name
- -A string used for identification purposes only. - -It has no semantics. Multiple threads may be given the same name. The -initial name is set by the constructor. - -
-
-
-
-native_id
- -_Readonly property_ - -Native integral thread ID of this thread, or None if it has not been started. - -This is a non-negative integer. See the get_native_id() function. -This represents the Thread ID as reported by the kernel. - -
-
-
-
-register(...)
- -Method: - -```python -register(self, path, iter_obj=None, iter_flags=1, priority=0, flags=0, subtype=None) -``` - -Register an iterator object at a specific path. - -Setting 'iter_obj' to None will internally use 'self' as the iterator -object which means that TwoPhaseSubscriber needs to be sub-classed. - -Operational and configuration subscriptions can be done on the -same TwoPhaseSubscriber, but in that case the notifications may be -arbitrarily interleaved, including operational notifications -arriving between different configuration notifications for the -same transaction. If this is a problem, use separate -TwoPhaseSubscriber instances for operational and configuration -subscriptions. - -For arguments and flags, see Subscriber.register() - -
-
-
-
-run(...)
- -Method: - -```python -run(self) -``` - -Main processing loop. - -
-
-
-
-setDaemon(...)
- -Method: - -```python -setDaemon(self, daemonic) -``` - -Set whether this thread is a daemon. - -This method is deprecated, use the .daemon property instead. - -
-
-
-
-setName(...)
- -Method: - -```python -setName(self, name) -``` - -Set the name string for this thread. - -This method is deprecated, use the name attribute instead. - -
-
-
-
-start(...)
- -Method: - -```python -start(self) -``` - -Start the subscriber. - -
-
-
-
-## Predefined Values
-
-```python
-
-A_CDB = 1
-DATA_SOCKET = 2
-DONE_OPERATIONAL = 4
-DONE_PRIORITY = 1
-DONE_SOCKET = 2
-DONE_TRANSACTION = 3
-FLAG_INIT = 1
-FLAG_UPGRADE = 2
-GET_MODS_CLI_NO_BACKQUOTES = 8
-GET_MODS_INCLUDE_LISTS = 1
-GET_MODS_INCLUDE_MOVES = 16
-GET_MODS_REVERSE = 2
-GET_MODS_SUPPRESS_DEFAULTS = 4
-GET_MODS_WANT_ANCESTOR_DELETE = 32
-LOCK_PARTIAL = 8
-LOCK_REQUEST = 4
-LOCK_SESSION = 2
-LOCK_WAIT = 1
-OPERATIONAL = 3
-O_CDB = 2
-PRE_COMMIT_RUNNING = 4
-READ_COMMITTED = 16
-READ_SOCKET = 0
-RUNNING = 1
-STARTUP = 2
-SUBSCRIPTION_SOCKET = 1
-SUB_ABORT = 3
-SUB_COMMIT = 2
-SUB_FLAG_HA_IS_SECONDARY = 16
-SUB_FLAG_HA_IS_SLAVE = 16
-SUB_FLAG_HA_SYNC = 8
-SUB_FLAG_IS_LAST = 1
-SUB_FLAG_REVERT = 4
-SUB_FLAG_TRIGGER = 2
-SUB_OPER = 4
-SUB_OPERATIONAL = 3
-SUB_PREPARE = 1
-SUB_RUNNING = 1
-SUB_RUNNING_TWOPHASE = 2
-SUB_WANT_ABORT_ON_ABORT = 1
-S_CDB = 3
-```
diff --git a/developer-reference/pyapi/ncs.dp.md b/developer-reference/pyapi/ncs.dp.md
deleted file mode 100644
index 99100623..00000000
--- a/developer-reference/pyapi/ncs.dp.md
+++ /dev/null
@@ -1,1241 +0,0 @@
-# Python ncs.dp Module
-
-Callback module for connecting data providers to ConfD/NCS.
-
-## Functions
-
-### return_worker_socket
-
-```python
-return_worker_socket(state, key)
-```
-
-Return worker socket associated with a worker thread from Daemon/state.
-
-Return worker socket to pool.
-
-### take_worker_socket
-
-```python
-take_worker_socket(state, name, key=None)
-```
-
-Take worker socket associated with a worker thread from Daemon/state.
-
-Take worker socket from pool, must be returned with
-dp.return_worker_socket after use.
-
-
-## Classes
-
-### _class_ **Action**
-
-Action callback.
-
-This class makes it easy to create and register action callbacks by
-sub-classing it and implementing cb_action in the derived class.
-
-```python
-Action(daemon, actionpoint, log=None, init_args=None)
-```
-
-Initialize this object.
-
-The 'daemon' argument should be a Daemon instance. 'actionpoint'
-is the name of the tailf:actionpoint to manage. 'log' can be any
-log object, and if not set the Daemon logger will be used.
-'init_args' may be any object that will be passed into init()
-when this object is constructed. Lastly, the low-level function
-dp.register_action_cbs() will be called.
-
-When using this class together with ncs.application.Application
-there is no need to manually initialize this object as it is
-done by the Application.register_action() method.
-
-Arguments:
-
-* daemon -- Daemon instance (dp.Daemon)
-* actionpoint -- actionpoint name (str)
-* log -- logging object (optional)
-* init_args -- additional arguments (optional)
-
-Members:
-
-stop(...)
- -Method: - -```python -stop(self) -``` - -Stop the subscriber. - -
-
-
-
-action(...)
- -Static method: - -```python -action(fn) -``` - -Decorator for the cb_action callback. - -Only use this decorator for actions of tailf:action type. - -Using this decorator alters the signature of the cb_action callback -and passes in maagic.Node objects for input and output action data. - -Example of a decorated cb_action: - - @Action.action - def cb_action(self, uinfo, name, kp, input, output, trans): - pass - -Callback arguments: - -* uinfo -- a UserInfo object -* name -- the tailf:action name (string) -* kp -- the keypath of the action (HKeypathRef) -* input -- input node (maagic.Node) -* output -- output node (maagic.Node) -* trans -- read only transaction, same as action transaction if - executed with an action context (maapi.Transaction) - -
-
-
-
-cb_init(...)
- -Method: - -```python -cb_init(self, uinfo) -``` - -The cb_init callback must always be implemented. - -This default implementation will associate a new worker socket -with this callback. - -
-
-
-
-init(...)
- -Method: - -```python -init(self, init_args) -``` - -Custom initialization. - -When registering an action using ncs.application.Application this -method will be called with the 'init_args' passed into the -register_action() function. - -
-
-
-
-rpc(...)
- -Static method: - -```python -rpc(fn) -``` - -Decorator for the cb_action callback. - -Only use this decorator for rpc:s. - -Using this decorator alters the signature of the cb_action callback -and passes in maagic.Node objects for input and output action data. - -Example of a decorated cb_action: - - @Action.rpc - def cb_action(self, uinfo, name, input, output): - pass - -Callback arguments: - -* uinfo -- a UserInfo object -* name -- the rpc name (string) -* input -- input node (maagic.Node) -* output -- output node (maagic.Node) - -
-
-
-
-start(...)
- -Method: - -```python -start(self) -``` - -Custom actionpoint start triggered when Python VM starts up. - -
-
-
-
-### _class_ **Daemon**
-
-Manage a data provider connection towards ConfD/NCS.
-
-```python
-Daemon(name, log=None, ip='127.0.0.1', port=4569, path=None, state_mgr=None)
-```
-
-Initialize a Daemon object.
-
-The 'name' argument should be unique. It will show up in the
-CLI and in error messages. All other arguments are optional.
-Argument 'log' can be any log object, and if not set the standard
-logging mechanism will be used. Set 'ip' and 'port' to
-where your Confd/NCS server is. 'path' is a filename to a unix
-domain socket to be used in place of 'ip' and 'port'. If 'path'
-is provided, 'ip' and 'port' arguments are ignored.
-
-Daemon supports automatic restarting in case of error if a
-state manager is provided using the state_mgr parameter.
-
-Members:
-
-stop(...)
- -Method: - -```python -stop(self) -``` - -Custom actionpoint stop triggered when Python VM shuts down. - -
-
-
-
-INIT_RETRY_INTERVAL_S
- -```python -INIT_RETRY_INTERVAL_S = 1 -``` - - -
-
-
-
-ctx(...)
- -Method: - -```python -ctx(self) -``` - -Return the daemon context. - -
-
-
-
-daemon
- -A boolean value indicating whether this thread is a daemon thread. - -This must be set before start() is called, otherwise RuntimeError is -raised. Its initial value is inherited from the creating thread; the -main thread is not a daemon thread and therefore all threads created in -the main thread default to daemon = False. - -The entire Python program exits when only daemon threads are left. - -
-
-
-
-finish(...)
- -Method: - -```python -finish(self) -``` - -Stop the daemon thread. - -
-
-
-
-getName(...)
- -Method: - -```python -getName(self) -``` - -Return a string used for identification purposes only. - -This method is deprecated, use the name attribute instead. - -
-
-
-
-ident
- -_Readonly property_ - -Thread identifier of this thread or None if it has not been started. - -This is a nonzero integer. See the get_ident() function. Thread -identifiers may be recycled when a thread exits and another thread is -created. The identifier is available even after the thread has exited. - -
-
-
-
-ip(...)
- -Method: - -```python -ip(self) -``` - -Return the ip address. - -
-
-
-
-isDaemon(...)
- -Method: - -```python -isDaemon(self) -``` - -Return whether this thread is a daemon. - -This method is deprecated, use the daemon attribute instead. - -
-
-
-
-is_alive(...)
- -Method: - -```python -is_alive(self) -``` - -Return whether the thread is alive. - -This method returns True just before the run() method starts until just -after the run() method terminates. See also the module function -enumerate(). - -
-
-
-
-join(...)
- -Method: - -```python -join(self, timeout=None) -``` - -Wait until the thread terminates. - -This blocks the calling thread until the thread whose join() method is -called terminates -- either normally or through an unhandled exception -or until the optional timeout occurs. - -When the timeout argument is present and not None, it should be a -floating point number specifying a timeout for the operation in seconds -(or fractions thereof). As join() always returns None, you must call -is_alive() after join() to decide whether a timeout happened -- if the -thread is still alive, the join() call timed out. - -When the timeout argument is not present or None, the operation will -block until the thread terminates. - -A thread can be join()ed many times. - -join() raises a RuntimeError if an attempt is made to join the current -thread as that would cause a deadlock. It is also an error to join() a -thread before it has been started and attempts to do so raises the same -exception. - -
-
-
-
-load_schemas(...)
- -Method: - -```python -load_schemas(self) -``` - -Load schema information into the process memory. - -
-
-
-
-name
- -A string used for identification purposes only. - -It has no semantics. Multiple threads may be given the same name. The -initial name is set by the constructor. - -
-
-
-
-native_id
- -_Readonly property_ - -Native integral thread ID of this thread, or None if it has not been started. - -This is a non-negative integer. See the get_native_id() function. -This represents the Thread ID as reported by the kernel. - -
-
-
-
-path(...)
- -Method: - -```python -path(self) -``` - -Return the unix domain socket path. - -
-
-
-
-port(...)
- -Method: - -```python -port(self) -``` - -Return the port. - -
-
-)
-```
-
-Register a transaction callback class.
-
-It's not necessary to call this method. Only do that if a custom
-transaction callback will be used.
-
-
-
-register_trans_cb(...)
- -Method: - -```python -register_trans_cb(self, trans_cb_cls=
-
-)
-```
-
-Register a transaction validation callback class.
-
-It's not necessary to call this method. Only do that if a custom
-transaction callback will be used.
-
-
-
-register_trans_validate_cb(...)
- -Method: - -```python -register_trans_validate_cb(self, trans_validate_cb_cls=
-
-
-
-run(...)
- -Method: - -```python -run(self) -``` - -Daemon thread processing loop. - -Don't call this method explicitly. It handles reading of control -and worker sockets and notifying ConfD/NCS that it should continue -processing by calling the low-level function dp.fd_ready(). -If the connection towards ConfD/NCS is broken or if finish() is -explicitly called, this function (and the thread) will end. - -
-
-
-
-setDaemon(...)
- -Method: - -```python -setDaemon(self, daemonic) -``` - -Set whether this thread is a daemon. - -This method is deprecated, use the .daemon property instead. - -
-
-
-
-setName(...)
- -Method: - -```python -setName(self, name) -``` - -Set the name string for this thread. - -This method is deprecated, use the name attribute instead. - -
-
-
-
-start(...)
- -Method: - -```python -start(self) -``` - -Start daemon work thread. - -After registering any callbacks (action, services and such), call -this function to start processing. The low-level function -dp.register_done() will be called before the thread is started. - -
-
-
-
-### _class_ **StateManager**
-
-Base class for state managers used with Daemon
-
-```python
-StateManager(log)
-```
-
-Members:
-
-wsock
- -_Readonly property_ - - -
-
-
-
-setup(...)
- -Method: - -```python -setup(self, state, previous_state) -``` - -Not Implemented. - -
-
-
-
-### _class_ **TransValidateCallback**
-
-Default transaction validation callback implementation class.
-
-When registering validation points in ConfD/NCS a transaction
-validation callback handler must be provided. This class is a
-generic implementation of such a handler. It implements the
-required callbacks 'cb_init' and 'cb_stop'.
-
-```python
-TransValidateCallback(state)
-```
-
-Initialize a TransValidateCallback object.
-
-The argument 'state' is the dict representation of a daemon.
-
-Members:
-
-teardown(...)
- -Method: - -```python -teardown(self, state, finished) -``` - -Not Implemented. - -
-
-
-
-cb_init(...)
- -Method: - -```python -cb_init(self, tctx) -``` - -The cb_init callback must always be implemented. - -It is required to prepare for future validation -callbacks. This default implementation allocates a worker -thread and socket pair and associates it with the transaction. - -
-
-
-
-### _class_ **TransactionCallback**
-
-Default transaction callback implementation class.
-
-When connecting data providers to ConfD/NCS a transaction callback
-handler must be provided. This class is a generic implementation of
-such a handler. It implements the only required callback 'cb_init'.
-
-```python
-TransactionCallback(state)
-```
-
-Initialize a TransactionCallback object.
-
-The argument 'wsock' is the connected worker socket and 'log'
-is a log object.
-
-Members:
-
-cb_stop(...)
- -Method: - -```python -cb_stop(self, tctx) -``` - -The cb_stop callback must always be implemented. - -Clean up resources previously allocated in the cb_init -callback. This default implementation returnes the worker -thread and socket pair to the pool of workers. - -
-
-
-
-cb_finish(...)
- -Method: - -```python -cb_finish(self, tctx) -``` - -The cb_finish callback of TransactionCallback. - -This implementation returns worker socket associated with a -worker thread from Daemon/state. - -
-
-
-
-### _class_ **ValidationError**
-
-Exception raised to indicate a failed validation
-
-
-```python
-ValidationError(message)
-```
-
-Members:
-
-cb_init(...)
- -Method: - -```python -cb_init(self, tctx) -``` - -The cb_init callback must always be implemented. - -It is required to prepare for future read/write operations towards -the data source. This default implementation associates a worker -socket with a transaction. - -
-
-
-
-add_note(...)
- -Method: - -Exception.add_note(note) -- -add a note to the exception - -
-
-
-
-args
- - -
-
-
-
-### _class_ **ValidationPoint**
-
-Validation Point callback.
-
-This class makes it easy to create and register validation point
-callbacks by subclassing it and implementing cb_validate with the
-@validate or @validate_with_trans decorator.
-
-```python
-ValidationPoint(daemon, validationpoint, log=None, init_args=None)
-```
-
-Members:
-
-with_traceback(...)
- -Method: - -Exception.with_traceback(tb) -- -set self.__traceback__ to tb and return self. - -
-
-
-
-init(...)
- -Method: - -```python -init(self, init_args) -``` - -Custom initialization. - -When registering a validation point using -ncs.application.Application this method will be called with -the 'init_args' passed into the register_validation() -function. - -
-
-
-
-start(...)
- -Method: - -```python -start(self) -``` - -Start ValidationPoint - -
-
-
-
-stop(...)
- -Method: - -```python -stop(self) -``` - -Stop ValidationPoint - -
-
-
-
-validate(...)
- -Static method: - -```python -validate(fn) -``` - -Decorator for the cb_validate callback. - -Using this decorator alters the signature of the cb_validate -callback and passes in the validationpoint as the last -argument. - -In addition it logs unhandled exceptions, handles -ValidationError exception setting the transaction error and -returns _tm.CONFD_ERR. - -Example of a decorated cb_validate: - - @ValidationPoint.validate - def cb_validate(self, tctx, keypath, value, validationpoint): - pass - -Callback arguments: - -* tctx - transaction context (TransCtxRef) -* kp -- path to the node being validated (HKeypathRef) -* value -- new value of keypath (Value) -* validationpoint - name of the validation point (str) - -
-
-
-
-## Predefined Values
-
-```python
-
-ACCESS_CHK_DESCENDANT = 1024
-ACCESS_CHK_FINAL = 512
-ACCESS_CHK_INTERMEDIATE = 256
-ACCESS_OP_CREATE = 4
-ACCESS_OP_DELETE = 16
-ACCESS_OP_EXECUTE = 2
-ACCESS_OP_READ = 1
-ACCESS_OP_UPDATE = 8
-ACCESS_OP_WRITE = 32
-ACCESS_RESULT_ACCEPT = 0
-ACCESS_RESULT_CONTINUE = 2
-ACCESS_RESULT_DEFAULT = 3
-ACCESS_RESULT_REJECT = 1
-BAD_VALUE_BAD_KEY_TAG = 32
-BAD_VALUE_BAD_LEXICAL = 19
-BAD_VALUE_BAD_TAG = 21
-BAD_VALUE_BAD_VALUE = 20
-BAD_VALUE_CUSTOM_FACET_ERROR_MESSAGE = 16
-BAD_VALUE_ENUMERATION = 11
-BAD_VALUE_FRACTION_DIGITS = 3
-BAD_VALUE_INVALID_FACET = 18
-BAD_VALUE_INVALID_REGEX = 9
-BAD_VALUE_INVALID_TYPE_NAME = 23
-BAD_VALUE_INVALID_UTF8 = 38
-BAD_VALUE_INVALID_XPATH = 34
-BAD_VALUE_INVALID_XPATH_AT_TAG = 40
-BAD_VALUE_INVALID_XPATH_PATH = 39
-BAD_VALUE_LENGTH = 15
-BAD_VALUE_MAX_EXCLUSIVE = 5
-BAD_VALUE_MAX_INCLUSIVE = 6
-BAD_VALUE_MAX_LENGTH = 14
-BAD_VALUE_MIN_EXCLUSIVE = 7
-BAD_VALUE_MIN_INCLUSIVE = 8
-BAD_VALUE_MIN_LENGTH = 13
-BAD_VALUE_MISSING_KEY = 37
-BAD_VALUE_MISSING_NAMESPACE = 27
-BAD_VALUE_NOT_RESTRICTED_XPATH = 35
-BAD_VALUE_NO_DEFAULT_NAMESPACE = 24
-BAD_VALUE_PATTERN = 12
-BAD_VALUE_POP_TOO_FAR = 31
-BAD_VALUE_RANGE = 29
-BAD_VALUE_STRING_FUN = 1
-BAD_VALUE_SYMLINK_BAD_KEY_REFERENCE = 33
-BAD_VALUE_TOTAL_DIGITS = 4
-BAD_VALUE_UNIQUELIST = 10
-BAD_VALUE_UNKNOWN_BIT_LABEL = 22
-BAD_VALUE_UNKNOWN_NAMESPACE = 26
-BAD_VALUE_UNKNOWN_NAMESPACE_PREFIX = 25
-BAD_VALUE_USER_ERROR = 17
-BAD_VALUE_VALUE2VALUE_FUN = 28
-BAD_VALUE_WRONG_DECIMAL64_FRACTION_DIGITS = 2
-BAD_VALUE_WRONG_NUMBER_IDENTIFIERS = 30
-BAD_VALUE_XPATH_ERROR = 36
-CLI_ACTION_NOT_FOUND = 13
-CLI_AMBIGUOUS_COMMAND = 63
-CLI_BAD_ACTION_RESPONSE = 16
-CLI_BAD_LEAF_VALUE = 6
-CLI_CDM_NOT_SUPPORTED = 74
-CLI_COMMAND_ABORTED = 2
-CLI_COMMAND_ERROR = 1
-CLI_COMMAND_FAILED = 3
-CLI_CONFIRMED_NOT_SUPPORTED = 39
-CLI_COPY_CONFIG_FAILED = 32
-CLI_COPY_FAILED = 31
-CLI_COPY_PATH_IDENTICAL = 33
-CLI_CREATE_PATH = 23
-CLI_CUSTOM_ERROR = 4
-CLI_DELETE_ALL_FAILED = 10
-CLI_DELETE_ERROR = 12
-CLI_DELETE_FAILED = 11
-CLI_ELEMENT_DOES_NOT_EXIST = 66
-CLI_ELEMENT_MANDATORY = 75
-CLI_ELEMENT_NOT_FOUND = 14
-CLI_ELEM_NOT_WRITABLE = 7
-CLI_EXPECTED_BOL = 56
-CLI_EXPECTED_EOL = 57
-CLI_FAILED_COPY_RUNNING = 38
-CLI_FAILED_CREATE_CONTEXT = 37
-CLI_FAILED_OPEN_STARTUP = 41
-CLI_FAILED_OPEN_STARTUP_CONFIG = 42
-CLI_FAILED_TERM_REDIRECT = 49
-CLI_ILLEGAL_DIRECTORY_NAME = 52
-CLI_ILLEGAL_FILENAME = 53
-CLI_INCOMPLETE_CMD_PATH = 67
-CLI_INCOMPLETE_COMMAND = 9
-CLI_INCOMPLETE_PATH = 8
-CLI_INCOMPLETE_PATTERN = 64
-CLI_INVALID_PARAMETER = 54
-CLI_INVALID_PASSWORD = 21
-CLI_INVALID_PATH = 58
-CLI_INVALID_ROLLBACK_NR = 15
-CLI_INVALID_SELECT = 59
-CLI_MESSAGE_TOO_LARGE = 48
-CLI_MISSING_ACTION_PARAM = 17
-CLI_MISSING_ACTION_PARAM_VALUE = 18
-CLI_MISSING_ARGUMENT = 69
-CLI_MISSING_DISPLAY_GROUP = 55
-CLI_MISSING_ELEMENT = 65
-CLI_MISSING_VALUE = 68
-CLI_MOVE_FAILED = 30
-CLI_MUST_BE_AN_INTEGER = 70
-CLI_MUST_BE_INTEGER = 43
-CLI_MUST_BE_TRUE_OR_FALSE = 71
-CLI_NOT_ALLOWED = 5
-CLI_NOT_A_DIRECTORY = 50
-CLI_NOT_A_FILE = 51
-CLI_NOT_FOUND = 28
-CLI_NOT_SUPPORTED = 34
-CLI_NOT_WRITABLE = 27
-CLI_NO_SUCH_ELEMENT = 45
-CLI_NO_SUCH_SESSION = 44
-CLI_NO_SUCH_USER = 47
-CLI_ON_LINE = 25
-CLI_ON_LINE_DESC = 26
-CLI_OPEN_FILE = 20
-CLI_READ_ERROR = 19
-CLI_REALLOCATE = 24
-CLI_SENSITIVE_DATA = 73
-CLI_SET_FAILED = 29
-CLI_START_REPLAY_FAILED = 72
-CLI_TARGET_EXISTS = 35
-CLI_UNKNOWN_ARGUMENT = 61
-CLI_UNKNOWN_COMMAND = 62
-CLI_UNKNOWN_ELEMENT = 60
-CLI_UNKNOWN_HIDEGROUP = 22
-CLI_UNKNOWN_MODE = 36
-CLI_WILDCARD_NOT_ALLOWED = 46
-CLI_WRITE_CONFIG_FAILED = 40
-COMPLETION = 0
-COMPLETION_DEFAULT = 3
-COMPLETION_DESC = 2
-COMPLETION_INFO = 1
-CONTROL_SOCKET = 0
-C_CREATE = 2
-C_MOVE_AFTER = 6
-C_REMOVE = 3
-C_SET_ATTR = 5
-C_SET_CASE = 4
-C_SET_ELEM = 1
-DAEMON_FLAG_BULK_GET_CONTAINER = 128
-DAEMON_FLAG_NO_DEFAULTS = 4
-DAEMON_FLAG_PREFER_BULK_GET = 64
-DAEMON_FLAG_REG_DONE = 65536
-DAEMON_FLAG_REG_REPLACE_DISCONNECT = 16
-DAEMON_FLAG_SEND_IKP = 1
-DAEMON_FLAG_STRINGSONLY = 2
-DATA_AFTER = 1
-DATA_BEFORE = 0
-DATA_CREATE = 0
-DATA_DELETE = 1
-DATA_FIRST = 2
-DATA_INSERT = 2
-DATA_LAST = 3
-DATA_MERGE = 3
-DATA_MOVE = 4
-DATA_REMOVE = 6
-DATA_REPLACE = 5
-DATA_WANT_FILTER = 1
-ERRTYPE_BAD_VALUE = 2
-ERRTYPE_CLI = 4
-ERRTYPE_MISC = 8
-ERRTYPE_NCS = 16
-ERRTYPE_OPERATION = 32
-ERRTYPE_VALIDATION = 1
-MISC_ACCESS_DENIED = 5
-MISC_APPLICATION = 19
-MISC_APPLICATION_INTERNAL = 20
-MISC_BAD_PERSIST_ID = 16
-MISC_CANDIDATE_ABORT_BAD_USID = 17
-MISC_CDB_OPER_UNAVAILABLE = 37
-MISC_DATA_MISSING = 44
-MISC_EXTERNAL = 22
-MISC_EXTERNAL_TIMEOUT = 45
-MISC_FILE_ACCESS_PATH = 33
-MISC_FILE_BAD_PATH = 34
-MISC_FILE_BAD_VALUE = 35
-MISC_FILE_CORRUPT = 52
-MISC_FILE_CREATE_PATH = 29
-MISC_FILE_DELETE_PATH = 32
-MISC_FILE_EOF = 36
-MISC_FILE_MOVE_PATH = 30
-MISC_FILE_OPEN_ERROR = 27
-MISC_FILE_SET_PATH = 31
-MISC_FILE_SYNTAX_ERROR = 28
-MISC_FILE_SYNTAX_ERROR_1 = 26
-MISC_HA_ABORT = 55
-MISC_INCONSISTENT_VALUE = 7
-MISC_INDEXED_VIEW_LIST_HOLE = 46
-MISC_INDEXED_VIEW_LIST_TOO_BIG = 18
-MISC_INTERNAL = 21
-MISC_INTERRUPT = 10
-MISC_IN_USE = 3
-MISC_LOCKED_BY = 4
-MISC_MISSING_INSTANCE = 8
-MISC_NODE_IS_READONLY = 13
-MISC_NODE_WAS_READONLY = 14
-MISC_NOT_IMPLEMENTED = 43
-MISC_NO_SUCH_FILE = 2
-MISC_OPERATION_NOT_SUPPORTED = 38
-MISC_PROTO_USAGE = 23
-MISC_REACHED_MAX_RETRIES = 56
-MISC_RESOLVE_NEEDED = 53
-MISC_RESOURCE_DENIED = 6
-MISC_ROLLBACK_DISABLED = 1
-MISC_ROTATE_LIST_KEY = 58
-MISC_SNMP_BAD_INDEX = 42
-MISC_SNMP_BAD_VALUE = 41
-MISC_SNMP_ERROR = 39
-MISC_SNMP_TIMEOUT = 40
-MISC_SUBAGENT_DOWN = 24
-MISC_SUBAGENT_ERROR = 25
-MISC_TOO_MANY_SESSIONS = 11
-MISC_TOO_MANY_TRANSACTIONS = 12
-MISC_TRANSACTION_CONFLICT = 54
-MISC_UNSUPPORTED_XML_ENCODING = 57
-MISC_UPGRADE_IN_PROGRESS = 15
-MISC_WHEN_FAILED = 9
-MISC_XPATH_COMPILE = 51
-NCS_BAD_AUTHGROUP_CALLBACK_RESPONSE = 104
-NCS_BAD_CAPAS = 14
-NCS_CALL_HOME = 107
-NCS_CLI_LOAD = 19
-NCS_COMMIT_QUEUED = 20
-NCS_COMMIT_QUEUED_AND_DELETED = 113
-NCS_COMMIT_QUEUE_DISABLED = 111
-NCS_COMMIT_QUEUE_HAS_OVERLAPPING = 103
-NCS_COMMIT_QUEUE_HAS_SENTINEL = 75
-NCS_CONFIG_LOCKED = 84
-NCS_CONFLICTING_INTENT = 125
-NCS_CONNECTION_CLOSED = 10
-NCS_CONNECTION_REFUSED = 5
-NCS_CONNECTION_TIMEOUT = 8
-NCS_CQ_BLOCK_OTHERS = 21
-NCS_CQ_REMOTE_NOT_ENABLED = 22
-NCS_DEV_AUTH_FAILED = 1
-NCS_DEV_IN_USE = 81
-NCS_HOST_LOOKUP = 12
-NCS_LOCKED = 3
-NCS_NCS_ACTION_NO_TRANSACTION = 67
-NCS_NCS_ALREADY_EXISTS = 82
-NCS_NCS_CLUSTER_AUTH_FAILED = 74
-NCS_NCS_DEV_ERROR = 69
-NCS_NCS_ERROR = 68
-NCS_NCS_ERROR_IKP = 70
-NCS_NCS_LOAD_TEMPLATE_COPY_TREE_CROSS_NS = 96
-NCS_NCS_LOAD_TEMPLATE_DUPLICATE_MACRO = 119
-NCS_NCS_LOAD_TEMPLATE_EOF_XML = 33
-NCS_NCS_LOAD_TEMPLATE_EXTRA_MACRO_VARS = 118
-NCS_NCS_LOAD_TEMPLATE_INVALID_CBTYPE = 128
-NCS_NCS_LOAD_TEMPLATE_INVALID_PI_REGEX = 122
-NCS_NCS_LOAD_TEMPLATE_INVALID_PI_SYNTAX = 86
-NCS_NCS_LOAD_TEMPLATE_INVALID_VALUE_XML = 30
-NCS_NCS_LOAD_TEMPLATE_MISPLACED_IF_NED_ID_MATCH_XML = 121
-NCS_NCS_LOAD_TEMPLATE_MISPLACED_IF_NED_ID_XML = 110
-NCS_NCS_LOAD_TEMPLATE_MISSING_ELEMENT2_XML = 98
-NCS_NCS_LOAD_TEMPLATE_MISSING_ELEMENT_XML = 29
-NCS_NCS_LOAD_TEMPLATE_MISSING_MACRO_VARS = 117
-NCS_NCS_LOAD_TEMPLATE_MULTIPLE_ELEMENTS_XML = 38
-NCS_NCS_LOAD_TEMPLATE_MULTIPLE_KEY_LEAFS_XML = 77
-NCS_NCS_LOAD_TEMPLATE_MULTIPLE_SP_XML = 35
-NCS_NCS_LOAD_TEMPLATE_SHADOWED_NED_ID_XML = 109
-NCS_NCS_LOAD_TEMPLATE_TAG_AMBIGUOUS_XML = 102
-NCS_NCS_LOAD_TEMPLATE_TRAILING_XML = 32
-NCS_NCS_LOAD_TEMPLATE_UNCLOSED_PI = 88
-NCS_NCS_LOAD_TEMPLATE_UNEXPECTED_PI = 89
-NCS_NCS_LOAD_TEMPLATE_UNKNOWN_ATTRIBUTE_XML = 31
-NCS_NCS_LOAD_TEMPLATE_UNKNOWN_ELEMENT2_XML = 97
-NCS_NCS_LOAD_TEMPLATE_UNKNOWN_ELEMENT_XML = 36
-NCS_NCS_LOAD_TEMPLATE_UNKNOWN_MACRO = 116
-NCS_NCS_LOAD_TEMPLATE_UNKNOWN_NED_ID_XML = 99
-NCS_NCS_LOAD_TEMPLATE_UNKNOWN_NS_XML = 37
-NCS_NCS_LOAD_TEMPLATE_UNKNOWN_PI = 85
-NCS_NCS_LOAD_TEMPLATE_UNKNOWN_SP_XML = 34
-NCS_NCS_LOAD_TEMPLATE_UNMATCHED_PI = 87
-NCS_NCS_LOAD_TEMPLATE_UNSUPPORTED_NED_ID_AT_TAG_XML = 101
-NCS_NCS_LOAD_TEMPLATE_UNSUPPORTED_NED_ID_XML = 100
-NCS_NCS_LOAD_TEMPLATE_UNSUPPORTED_NETCONF_YANG_ATTRIBUTES = 126
-NCS_NCS_MISSING_CLUSTER_AUTH = 73
-NCS_NCS_MISSING_VARIABLES = 52
-NCS_NCS_NED_MULTI_ERROR = 76
-NCS_NCS_NO_CAPABILITIES = 64
-NCS_NCS_NO_DIFF = 71
-NCS_NCS_NO_FORWARD_DIFF = 72
-NCS_NCS_NO_NAMESPACE = 65
-NCS_NCS_NO_SP_TEMPLATE = 48
-NCS_NCS_NO_TEMPLATE = 47
-NCS_NCS_NO_TEMPLATE_XML = 23
-NCS_NCS_NO_WRITE_TRANSACTION = 66
-NCS_NCS_OPERATION_LOCKED = 83
-NCS_NCS_PACKAGE_SYNC_MISMATCHED_LOAD_PATH = 123
-NCS_NCS_SERVICE_CONFLICT = 78
-NCS_NCS_TEMPLATE_CONTEXT_NODE_NOEXISTS = 90
-NCS_NCS_TEMPLATE_COPY_TREE_BAD_OP = 94
-NCS_NCS_TEMPLATE_FOREACH = 51
-NCS_NCS_TEMPLATE_FOREACH_XML = 28
-NCS_NCS_TEMPLATE_GUARD_LENGTH = 59
-NCS_NCS_TEMPLATE_GUARD_LENGTH_XML = 44
-NCS_NCS_TEMPLATE_INSERT = 55
-NCS_NCS_TEMPLATE_INSERT_XML = 40
-NCS_NCS_TEMPLATE_LONE_GUARD = 57
-NCS_NCS_TEMPLATE_LONE_GUARD_XML = 42
-NCS_NCS_TEMPLATE_LOOP_PREVENTION = 95
-NCS_NCS_TEMPLATE_MISSING_VALUE = 56
-NCS_NCS_TEMPLATE_MISSING_VALUE_XML = 41
-NCS_NCS_TEMPLATE_MOVE = 60
-NCS_NCS_TEMPLATE_MOVE_XML = 45
-NCS_NCS_TEMPLATE_MULTIPLE_CONTEXT_NODES = 92
-NCS_NCS_TEMPLATE_NOT_CREATED = 80
-NCS_NCS_TEMPLATE_NOT_CREATED_XML = 79
-NCS_NCS_TEMPLATE_ORDERED_LIST = 54
-NCS_NCS_TEMPLATE_ORDERED_LIST_XML = 39
-NCS_NCS_TEMPLATE_ROOT_LEAF_LIST = 93
-NCS_NCS_TEMPLATE_SAVED_CONTEXT_NOEXISTS = 91
-NCS_NCS_TEMPLATE_STR2VAL = 61
-NCS_NCS_TEMPLATE_STR2VAL_XML = 46
-NCS_NCS_TEMPLATE_UNSUPPORTED_NED_ID = 112
-NCS_NCS_TEMPLATE_VALUE_LENGTH = 58
-NCS_NCS_TEMPLATE_VALUE_LENGTH_XML = 43
-NCS_NCS_TEMPLATE_WHEN = 50
-NCS_NCS_TEMPLATE_WHEN_KEY_XML = 27
-NCS_NCS_TEMPLATE_WHEN_XML = 26
-NCS_NCS_XPATH = 53
-NCS_NCS_XPATH_COMPILE = 49
-NCS_NCS_XPATH_COMPILE_XML = 24
-NCS_NCS_XPATH_VARBIND = 63
-NCS_NCS_XPATH_XML = 25
-NCS_NED_EXTERNAL_ERROR = 6
-NCS_NED_INTERNAL_ERROR = 7
-NCS_NED_OFFLINE_UNAVAILABLE = 108
-NCS_NED_OUT_OF_SYNC = 18
-NCS_NONED = 15
-NCS_NO_EXISTS = 2
-NCS_NO_TEMPLATE = 62
-NCS_NO_YANG_MODULES = 16
-NCS_NS_SUPPORT = 13
-NCS_OVERLAPPING_PRESENCE_AND_ABSENCE_ASSERTION_COMPLIANCE_TEMPLATE = 127
-NCS_OVERLAPPING_STRICT_ASSERTION_COMPLIANCE_TEMPLATE = 129
-NCS_PLAN_LOCATION = 120
-NCS_REVDROP = 17
-NCS_RPC_ERROR = 9
-NCS_SERVICE_CREATE = 0
-NCS_SERVICE_DELETE = 2
-NCS_SERVICE_UPDATE = 1
-NCS_SESSION_LIMIT_EXCEEDED = 115
-NCS_SOUTHBOUND_LOCKED = 4
-NCS_UNKNOWN_NED_ID = 105
-NCS_UNKNOWN_NED_IDS_COMPLIANCE_TEMPLATE = 124
-NCS_UNKNOWN_NED_ID_DEVICE_TEMPLATE = 106
-NCS_XML_PARSE = 11
-NCS_YANGLIB_NO_SCHEMA_FOR_RUNNING = 114
-OPERATION_CASE_EXISTS = 13
-PATCH_FLAG_AAA_CHECKED = 8
-PATCH_FLAG_BUFFER_DAMPENED = 2
-PATCH_FLAG_FILTER = 4
-PATCH_FLAG_INCOMPLETE = 1
-WORKER_SOCKET = 1
-```
diff --git a/developer-reference/pyapi/ncs.experimental.md b/developer-reference/pyapi/ncs.experimental.md
deleted file mode 100644
index 062268a8..00000000
--- a/developer-reference/pyapi/ncs.experimental.md
+++ /dev/null
@@ -1,242 +0,0 @@
-# Python ncs.experimental Module
-
-Experimental stuff.
-
-This module contains experimental and totally unsupported things that
-may change or disappear at any time in the future. If used, it must be
-explicitly imported.
-
-## Classes
-
-### _class_ **DataCallbacks**
-
-High-level API for implementing data callbacks.
-
-Higher level abstraction for the DP API. Currently supports read
-operations only, as such it is suitable for config false; data.
-
-Registered callbacks are searched for in registration order. Most
-specific points must be registered first.
-
-args parameter to handler callbacks is a dictionary with keys
-matching list names in the keypath. If multiple lists with the
-same name exists the keys are named list-0, list-1 etc where 0 is
-the top-most list with name list. Values in the dictionary are
-python types (.as_pyval()), if the list has multiple keys it is
-set as a list else the single key value is set.
-
-Example args for keypath
-/root/single-key-list{name}/conflict{first}/conflict{second}/multi{1 one}
-
- {'single-key-list': 'name',
- 'conflict-0': 'first',
- 'conflict-1': 'second',
- 'multi': [1, 'one']}
-
-Example handler and registration:
-
- class Handler(object):
- def get_object(self, tctx, kp, args):
- return {'leaf1': 'value', 'leaf2': 'value'}
-
- def get_next(self, tctx, kp, args, next):
- return None
-
- def count(self):
- return 0
-
- dcb = DataCallbacks(log)
- dcb.register('/namespace:container', Handler())
- _confd.dp.register_data_cb(dd.ctx(), example_ns.callpoint_handler, dcb)
-
-```python
-DataCallbacks(log)
-```
-
-Members:
-
-validate_with_trans(...)
- -Static method: - -```python -validate_with_trans(fn) -``` - -Decorator for the cb_validate callback. - -Using this decorator alters the signature of the cb_validate -callback and passes in root node attached to the transaction -being validated and the validationpoint as the last argument. - -In addition it logs unhandled exceptions, handles -ValidationError exception setting the transaction error and -returns _tm.CONFD_ERR. - -Example of a decorated cb_validate: - - @ValidationPoint.validate_with_trans - def cb_validate(self, tctx, root, kp, value, validationpoint): - pass - -Callback arguments: - -* tctx - transaction context (TransCtxRef) -* root -- root node (maagic.Root) -* kp -- path to the node being validated (HKeypathRef) -* value -- new value of keypath (Value) -* validationpoint - name of the validation point (str) - -
-
-
-
-cb_exists_optional(...)
- -Method: - -```python -cb_exists_optional(self, tctx, kp) -``` - -low-level cb_exists_optional implementation - -
-
-
-
-cb_get_case(...)
- -Method: - -```python -cb_get_case(self, tctx, kp, choice) -``` - -low-level cb_get_case implementation - -
-
-
-
-cb_get_elem(...)
- -Method: - -```python -cb_get_elem(self, tctx, kp) -``` - -low-level cb_elem implementation - -
-
-
-
-cb_get_next(...)
- -Method: - -```python -cb_get_next(self, tctx, kp, next) -``` - -low-level cb_get_next implementation - -
-
-
-
-cb_get_next_object(...)
- -Method: - -```python -cb_get_next_object(self, tctx, kp, next) -``` - -low-level cb_get_next_object implementation - -
-
-
-
-cb_get_object(...)
- -Method: - -```python -cb_get_object(self, tctx, kp) -``` - -low-level cb_get_object implementation - -
-
-
-
-cb_num_instances(...)
- -Method: - -```python -cb_num_instances(self, tctx, kp) -``` - -low-level cb_num_instances implementation - -
-
-
-
-### _class_ **Query**
-
-Class encapsulating a MAAPI query operation.
-
-Supports the pattern of executing a query and iterating over the result
-sets as they are requested. The class handles the calls to query_start,
-query_result and query_stop, which means that one can focus on describing
-the query and handle the result.
-
-Example query:
-
- with Query(trans, 'device', '/devices', ['name', 'address', 'port'],
- result_as=ncs.QUERY_TAG_VALUE) as q:
- for r in q:
- print(r)
-
-```python
-Query(trans, expr, context_node, select, chunk_size=1000, initial_offset=1, result_as=3, sort=[])
-```
-
-Initialize a Query.
-
-Members:
-
-register(...)
- -Method: - -```python -register(self, path, handler) -``` - -Register data handler for path. - -If handler is a type it will be instantiated with the DataCallbacks -log as the only parameter. - -The following methods will be called on the handler: - -* get_object(kp, args) - - Return single object as dictionary. - -* get_next(kp, args, next) - - Return next object as dictionary, list of dictionaries can be - returned to use result caching reducing the amount of calls - required. - -* count(kp, args) - - Return number of elements in list. - -
-
-
-
-next(...)
- -Method: - -```python -next(self) -``` - -Get the next query result row. - -
-
-
-
diff --git a/developer-reference/pyapi/ncs.log.md b/developer-reference/pyapi/ncs.log.md
deleted file mode 100644
index 20b3961a..00000000
--- a/developer-reference/pyapi/ncs.log.md
+++ /dev/null
@@ -1,517 +0,0 @@
-# Python ncs.log Module
-
-This module provides some logging utilities.
-
-## Functions
-
-### init_logging
-
-```python
-init_logging(vmid, log_file, log_level)
-```
-
-Initialize logging
-
-### log_datefmt
-
-```python
-log_datefmt()
-```
-
-Return date format used in logging.
-
-### log_file
-
-```python
-log_file()
-```
-
-Return log file used, if any else None
-
-### log_format
-
-```python
-log_format()
-```
-
-Return log format.
-
-### log_handler
-
-```python
-log_handler()
-```
-
-Return log handler used, if any else None
-
-### mk_log_formatter
-
-```python
-mk_log_formatter()
-```
-
-Create log formatter with log and date format setup
-
-### reopen_logs
-
-```python
-reopen_logs()
-```
-
-Re-open log files if log handler is set
-
-### set_log_level
-
-```python
-set_log_level(vmid, log_level)
-```
-
-Set log level on the vmid logger and root logger
-
-
-## Classes
-
-### _class_ **Log**
-
-A log helper class.
-
-This class makes it easier to write log entries. It encapsulates
-another log object that supports Python standard log interface, and
-makes it easier to format the log message be adding the ability to
-support multiple arguments.
-
-Example use:
-
- import logging
- import confd.log
-
- logger = logging.getLogger(__name__)
- mylog = confd.log.Log(logger)
-
- count = 3
- name = 'foo'
- mylog.debug('got ', count, ' values from ', name)
-
-```python
-Log(logobject, add_timestamp=False)
-```
-
-Initialize a Log object.
-
-The argument 'logobject' is mandatory and can be any object which
-should support as least one of the standard log methods (info, warning,
-error, critical, debug). If 'add_timestamp' is set to True a time stamp
-will precede your log message.
-
-Members:
-
-stop(...)
- -Method: - -```python -stop(self) -``` - -Stop the running query. - -Any resources associated with the query will be released. - -
-
-
-
-critical(...)
- -Method: - -```python -critical(self, *args) -``` - -Log a critical message. - -
-
-
-
-debug(...)
- -Method: - -```python -debug(self, *args) -``` - -Log a debug message. - -
-
-
-
-error(...)
- -Method: - -```python -error(self, *args) -``` - -Log an error message. - -
-
-
-
-exception(...)
- -Method: - -```python -exception(self, *args) -``` - -Log an exception message. - -
-
-
-
-fatal(...)
- -Method: - -```python -fatal(self, *args) -``` - -Just calls critical(). - -
-
-
-
-info(...)
- -Method: - -```python -info(self, *args) -``` - -Log an information message. - -
-
-
-
-### _class_ **ParentProcessLogHandler**
-
-
-```python
-ParentProcessLogHandler(log_q)
-```
-
-Members:
-
-warning(...)
- -Method: - -```python -warning(self, *args) -``` - -Log a warning message. - -
-
-
-
-acquire(...)
- -Method: - -```python -acquire(self) -``` - -Acquire the I/O thread lock. - -
-
-
-
-addFilter(...)
- -Method: - -```python -addFilter(self, filter) -``` - -Add the specified filter to this handler. - -
-
-
-
-close(...)
- -Method: - -```python -close(self) -``` - -Tidy up any resources used by the handler. - -This version removes the handler from an internal map of handlers, -_handlers, which is used for handler lookup by name. Subclasses -should ensure that this gets called from overridden close() -methods. - -
-
-
-
-createLock(...)
- -Method: - -```python -createLock(self) -``` - -Acquire a thread lock for serializing access to the underlying I/O. - -
-
-
-
-emit(...)
- -Method: - -```python -emit(self, record) -``` - -Emit log record by sending a pre-formatted record to the parent -process - -
-
-
-
-filter(...)
- -Method: - -```python -filter(self, record) -``` - -Determine if a record is loggable by consulting all the filters. - -The default is to allow the record to be logged; any filter can veto -this by returning a false value. -If a filter attached to a handler returns a log record instance, -then that instance is used in place of the original log record in -any further processing of the event by that handler. -If a filter returns any other true value, the original log record -is used in any further processing of the event by that handler. - -If none of the filters return false values, this method returns -a log record. -If any of the filters return a false value, this method returns -a false value. - -.. versionchanged:: 3.2 - - Allow filters to be just callables. - -.. versionchanged:: 3.12 - Allow filters to return a LogRecord instead of - modifying it in place. - -
-
-
-
-flush(...)
- -Method: - -```python -flush(self) -``` - -Flushes the stream. - -
-
-
-
-format(...)
- -Method: - -```python -format(self, record) -``` - -Format the specified record. - -If a formatter is set, use it. Otherwise, use the default formatter -for the module. - -
-
-
-
-get_name(...)
- -Method: - -```python -get_name(self) -``` - - -
-
-
-
-handle(...)
- -Method: - -```python -handle(self, record) -``` - -Conditionally emit the specified logging record. - -Emission depends on filters which may have been added to the handler. -Wrap the actual emission of the record with acquisition/release of -the I/O thread lock. - -Returns an instance of the log record that was emitted -if it passed all filters, otherwise a false value is returned. - -
-
-
-
-handleError(...)
- -Method: - -```python -handleError(self, record) -``` - -Handle errors which occur during an emit() call. - -This method should be called from handlers when an exception is -encountered during an emit() call. If raiseExceptions is false, -exceptions get silently ignored. This is what is mostly wanted -for a logging system - most users will not care about errors in -the logging system, they are more interested in application errors. -You could, however, replace this with a custom handler if you wish. -The record which was being processed is passed in to this method. - -
-
-
-
-name
- - -
-
-
-
-release(...)
- -Method: - -```python -release(self) -``` - -Release the I/O thread lock. - -
-
-
-
-removeFilter(...)
- -Method: - -```python -removeFilter(self, filter) -``` - -Remove the specified filter from this handler. - -
-
-
-
-setFormatter(...)
- -Method: - -```python -setFormatter(self, fmt) -``` - -Set the formatter for this handler. - -
-
-
-
-setLevel(...)
- -Method: - -```python -setLevel(self, level) -``` - -Set the logging level of this handler. level must be an int or a str. - -
-
-
-
-setStream(...)
- -Method: - -```python -setStream(self, stream) -``` - -Sets the StreamHandler's stream to the specified value, -if it is different. - -Returns the old stream, if the stream was changed, or None -if it wasn't. - -
-
-
-
-set_name(...)
- -Method: - -```python -set_name(self, name) -``` - - -
-
-
-
diff --git a/developer-reference/pyapi/ncs.maagic.md b/developer-reference/pyapi/ncs.maagic.md
deleted file mode 100644
index 26964e75..00000000
--- a/developer-reference/pyapi/ncs.maagic.md
+++ /dev/null
@@ -1,1391 +0,0 @@
-# Python ncs.maagic Module
-
-Confd/NCS data access module.
-
-This module implements classes and function for easy access to the data store.
-There is no need to manually instantiate any of the classes herein. The only
-functions that should be used are cd(), get_node() and get_root().
-
-## Functions
-
-### as_pyval
-
-```python
-as_pyval(mobj, name_type=3, include_oper=False, enum_as_string=True)
-```
-
-Convert maagic object to python value.
-
-The types are converted as follows:
-
-* List is converted to list.
-* Container is converted to dict.
-* Leaf is converted to python value.
-* EmptyLeaf is converted to bool.
-* ActionParams is converted to dict.
-
-If include_oper is False and and a oper Node is
-passed then None is returned.
-
-Arguments:
-
-* mobj -- maagic object (maagic.Enum, maagic.Bits, maagic.Node)
-* name_type -- one of NODE_NAME_SHORT, NODE_NAME_FULL,
-NODE_NAME_PY_SHORT and NODE_NAME_PY_FULL and controls dictionary
-key names
-* include_oper -- include operational data (boolean)
-* enum_as_string -- return enumerator in str form (boolean)
-
-### cd
-
-```python
-cd(node, path)
-```
-
-Return the node at path 'path', starting from node 'node'.
-
-Arguments:
-
-* path -- relative or absolute keypath as a string (HKeypathRef or
- maagic.Node)
-
-Returns:
-
-* node (maagic.Node)
-
-### get_maapi
-
-```python
-get_maapi(obj)
-```
-
-Get Maapi object from obj.
-
-Return Maapi object from obj. raise BackendError if
-provided object does not contain a Maapi object.
-
-Arguements:
-
-* object (obj)
-
-Returns:
-
-* maapi object (maapi.Maapi)
-
-### get_memory_node
-
-```python
-get_memory_node(backend_or_node, path)
-```
-
-Return a Node at 'path' using 'backend' only for schema information.
-
-All operations towards the returned Node is cached in memory and not
-communicated to the server. This can be useful for effectively building a
-large data set which can later be converted to a TagValue array by calling
-get_tagvalues() or written directly to the server by calling
-set_memory_tree() and shared_set_memory_tree().
-
-Arguments:
-
-* backend_or_node -- backend or node object for reading schema
- information under mount points (maagic.Node,
- maapi.Transaction or maapi.Maapi)
-* path -- absolute keypath as a string (HKeypathRef or maagic.Node)
-
-Example use:
-
- conf = ncs.maagic.get_memory_node(t, '/ncs:devices/device{ce0}/conf')
-
-### get_memory_root
-
-```python
-get_memory_root(backend_or_node)
-```
-
-Return Root object with a memory-only backend.
-
-The passed in 'backend' is only used to read schema information when
-traversing past a mount point. All operations towards the returned Node is
-cached in memory and not communicated to the server.
-
-Arguments:
-
-* backend_or_node -- backend or node object for reading schema
- information under mount points (maagic.Node,
- maapi.Transaction or maapi.Maapi)
-
-### get_node
-
-```python
-get_node(backend_or_node, path, shared=False)
-```
-
-Return the node at path 'path' using 'backend'.
-
-Arguments:
-
-* backend_or_node -- backend object (maapi.Transaction, maapi.Maapi or None)
- or maapi.Node.
-* path -- relative or absolute keypath as a string (HKeypathRef or
- maagic.Node). Relative paths are only supported if backend_or_node
- is a maagic.Node.
-* shared -- if set to 'True', fastmap-friendly maapi calls, such as
- shared_set_elem, will be used within the returned tree (boolean)
-
-Example use:
-
- node = ncs.maagic.get_node(t, '/ncs:devices/device{ce0}')
-
-### get_root
-
-```python
-get_root(backend=None, shared=False)
-```
-
-Return a Root object for 'backend'.
-
-If 'backend' is a Transaction object, the returned Maagic object can be
-used to read and write transactional data. When 'backend' is a Maapi
-object you cannot read and write data, however, you may use the Maagic
-object to call an action (that doesn't require a transaction).
-If 'backend' is a Node object the underlying Transaction or Maapi object
-will be used (if any), otherwise backend will be assumed to be None.
-'backend' may also be None (default) in which case the returned Maagic
-object is not connected to NCS in any way. You can still use the maagic
-object to build an in-memory tree which may be converted to an array
-of TagValue objects.
-
-Arguments:
-
-* backend -- backend object (maagic.Node, maapi.Transaction, maapi.Maapi
- or None)
-* shared -- if set to 'True', fastmap-friendly maapi calls, such as
- shared_set_elem, will be used within the returned tree (boolean)
-
-Returns:
-
-* root node (maagic.Root)
-
-Example use:
-
- with ncs.maapi.Maapi() as m:
- with ncs.maapi.Session(m, 'admin', 'python'):
- root = ncs.maagic.get_root(m)
-
-### get_tagvalues
-
-```python
-get_tagvalues(node)
-```
-
-Return a list of TagValue's representing 'node'.
-
-Arguments:
-
-* node -- A Node object.
-
-### get_trans
-
-```python
-get_trans(node_or_trans)
-```
-
-Get Transaction object from node_or_trans.
-
-Return Transaction object from node_or_trans. Raise BackendError if
-provided object does not contain a Transaction object.
-
-### set_memory_tree
-
-```python
-set_memory_tree(node, trans_obj=None)
-```
-
-Calls Maapi.set_values() using using TagValue's from 'node'.
-
-The backend specified when obtaining the initial node, most likely by using
-'get_memory_node()' or 'get_memory_root()', will be used if that is a
-maapi.Transaction backend, otherwise 'trans_obj' will be used.
-
-Arguments:
-
-* node -- a Node object (Node)
-* trans_obj -- another transaction object to use in case node's backend is
- not a transaction backend (Node or maapi.Transaction)
-
-### set_values_xml
-
-```python
-set_values_xml(node, xml)
-```
-
-Parses the XML document in 'xml' and sets values in the transaction.
-
-The XML document must be explicit with regards to namespaces and tags and
-the top node must represent the corresponding 'node' object.
-
-### shared_set_memory_tree
-
-```python
-shared_set_memory_tree(node, trans_obj=None)
-```
-
-Calls Maapi.shared_set_values() using using TagValue's from 'node'.
-
-For use in FASTMAP code (services). See set_memory_tree().
-
-### shared_set_values_xml
-
-```python
-shared_set_values_xml(node, xml)
-```
-
-Parses the XML document in 'xml' and sets values in the transaction.
-
-The XML document must be explicit with regards to namespaces and tags and
-the top node must represent the corresponding 'node' object. This variant
-is to be used in services where FASTMAP attributes must be preserved.
-
-
-## Classes
-
-### _class_ **Action**
-
-Represents a tailf:action node.
-
-```python
-Action(backend, cs_node, parent=None)
-```
-
-Initialize an Action node. Should not be called explicitly.
-
-Members:
-
-terminator
- -```python -terminator = '\n' -``` - - -
-
-
-
-get_input(...)
- -Method: - -```python -get_input(self) -``` - -Return a node tree representing the input node of this action. - -Returns: - -* action inputs (maagic.ActionParams) - -
-
-
-
-get_output(...)
- -Method: - -```python -get_output(self) -``` - -Return a node tree representing the output node of this action. - -Note that this does not actually request the action. -Should not normally be called explicitly. - -Returns: - -* action outputs (maagic.ActionParams) - -
-
-
-
-### _class_ **ActionParams**
-
-Represents the input or output parameters of a tailf:action.
-
-The ActionParams node is the root of a tree representing either the input
-or the output parameters of an action. Action parameters can be read and
-set just like any other nodes in the tree.
-
-```python
-ActionParams(cs_node, parent, output=False)
-```
-
-Initialize an ActionParams node.
-
-Should not be called explicitly. Use 'get_input()' on an Action node
-to retrieve its input parameters or 'request()' to request the action
-and obtain the output parameters.
-
-Members:
-
-_None_
-
-### _class_ **BackendError**
-
-Exception type used within maagic backends.
-
-Members:
-
-request(...)
- -Method: - -```python -request(self, params=None) -``` - -Request the action and return the result as an ActionParams node. - -Arguments: - -* params -- input parameters of the action (maagic.ActionParams, - optional) - -Returns: - -* outparams -- output parameters of the action (maagic.ActionParams) - -
-
-
-
-add_note(...)
- -Method: - -Exception.add_note(note) -- -add a note to the exception - -
-
-
-
-args
- - -
-
-
-
-### _class_ **Bits**
-
-Representation of a YANG bits leaf with position > 63.
-
-```python
-Bits(value, cs_node=None)
-```
-
-Initialize a Bits object.
-
-Note that a Bits object has no connection to the YANG model and will
-not check that the given value matches the string representation
-according to the schema. Normally it is not necessary to create
-Bits objects using this constructor as bits leaves can be set using
-bytearrays alone.
-
-Attributes:
-
-* value -- a Value object of type C_BITBIG
-* cs_node -- a CsNode representing the YANG bits leaf. Without this
- you cannot get a string representation of the bits
- value; in that case repr(self) will be returned for
- the str() call. (default: None)
-
-Members:
-
-with_traceback(...)
- -Method: - -Exception.with_traceback(tb) -- -set self.__traceback__ to tb and return self. - -
-
-
-
-bytearray(...)
- -Method: - -```python -bytearray(self) -``` - -Return a 'little-endian' byte array. - -
-
-
-
-clr_bit(...)
- -Method: - -```python -clr_bit(self, position) -``` - -Clear a bit at a specific position in the internal byte array. - -
-
-
-
-is_bit_set(...)
- -Method: - -```python -is_bit_set(self, position) -``` - -Check if a bit at a specific position is set. - -
-
-
-
-### _class_ **Case**
-
-Represents a case node.
-
-If this case node has any nested choice nodes, those will appear as
-children of this object.
-
-```python
-Case(backend, cs_node, cs_case, parent)
-```
-
-Initialize a Case node. Should not be called explicitly.
-
-Members:
-
-_None_
-
-### _class_ **Choice**
-
-Represents a choice node.
-
-```python
-Choice(backend, cs_node, cs_choice, parent)
-```
-
-Initialize a Choice node. Should not be called explicitly.
-
-Members:
-
-set_bit(...)
- -Method: - -```python -set_bit(self, position) -``` - -Set a bit at a specific position in the internal byte array. - -
-
-
-
-### _class_ **Container**
-
-Represents a YANG container.
-
-A (non-presence) container node or a list element, contains other nodes.
-
-```python
-Container(backend, cs_node, parent=None, children=None)
-```
-
-Initialize Container node. Should not be called explicitly.
-
-Members:
-
-get_value(...)
- -Method: - -```python -get_value(self) -``` - -Return the currently selected case of this choice. - -The case is returned as a Case node. If no case is selected for this -choice, None is returned. - -Returns: - -* current selection of choice (maagic.Case) - -
-
-
-
-### _class_ **Empty**
-
-Simple represention of a yang empty value.
-
-This is used to represent an empty value in unions and list keys.
-
-```python
-Empty()
-```
-
-Initialize an Empty object.
-
-Members:
-
-_None_
-
-### _class_ **EmptyLeaf**
-
-Represents a leaf with the type "empty".
-
-```python
-EmptyLeaf(backend, cs_node, parent=None)
-```
-
-Initialize an EmptyLeaf node. Should not be called explicitly.
-
-Members:
-
-delete(...)
- -Method: - -```python -delete(self) -``` - -Delete the container. - -Deletes all nodes inside the container. The container itself is not -affected as it carries no state of its own. - -Example use: - - root.container.delete() - -
-
-
-
-create(...)
- -Method: - -```python -create(self) -``` - -Create and return this leaf in the data tree. - -
-
-
-
-delete(...)
- -Method: - -```python -delete(self) -``` - -Delete this leaf from the data tree. - -
-
-
-
-### _class_ **Enum**
-
-Simple represention of a YANG enumeration instance.
-
-Contains the string and integer representation of the enumeration.
-An Enum object supports comparisons with other 'Enum' objects as well as
-with other objects. For equality checks, strings, numbers, 'Enum' objects
-and 'Value' objects are allowed. For relational operators,
-all of the above except strings are acceptable.
-
-Attributes:
-
-* string -- string representation of the enumeration
-* value -- integer representation of the enumeration
-
-```python
-Enum(string, value)
-```
-
-Initialize an Enum object from a given string and integer.
-
-Note that an Enum object has no connection to the YANG model and will
-not check that the given value matches the string representation
-according to the schema. Normally it is not necessary to create
-Enum objects using this constructor as enum leaves can be set using
-strings alone.
-
-Arguments:
-
-* string -- string representation of the enumeration (str)
-* value -- integer representation of the enumeration (int)
-
-Members:
-
-_None_
-
-### _class_ **Leaf**
-
-Base class for leaf nodes.
-
-Subclassed by NonEmptyLeaf, EmptyLeaf and LeafList.
-
-```python
-Leaf(backend, cs_node, parent=None)
-```
-
-Initialize Leaf node. Should not be called explicitly.
-
-Members:
-
-exists(...)
- -Method: - -```python -exists(self) -``` - -Return True if this leaf exists in the data tree. - -
-
-
-
-### _class_ **LeafList**
-
-Represents a leaf-list node.
-
-```python
-LeafList(backend, cs_node, parent=None)
-```
-
-Initialize a LeafList node. Should not be called explicitly.
-
-Members:
-
-delete(...)
- -Method: - -```python -delete(self) -``` - -Delete this leaf from the data tree. - -Example use: - - root.model.leaf.delete() - -
-
-
-
-as_list(...)
- -Method: - -```python -as_list(self) -``` - -Return leaf-list values in a list. - -Returns: - -* leaf list values (list) - -Example use: - - root.model.ll.as_list() - -
-
-
-
-create(...)
- -Method: - -```python -create(self, key) -``` - -Create a new leaf-list item. - -Arguments: - -* key -- item key (str or maapi.Key) - -Example use: - - root.model.ll.create('example') - -
-
-
-
-delete(...)
- -Method: - -```python -delete(self) -``` - -Delete the entire leaf-list. - -Example use: - - root.model.ll.delete() - -
-
-
-
-exists(...)
- -Method: - -```python -exists(self) -``` - -Return true if the leaf-list exists (has values) in the data tree. - -Example use: - - if root.model.ll.exists(): - do_things() - -
-
-
-
-remove(...)
- -Method: - -```python -remove(self, key) -``` - -Remove a specific leaf-list item'. - -Arguments: - -* key -- item key (str or maapi.Key) - -Example use: - - root.model.ll.remove('example') - -
-
-
-
-### _class_ **LeafListIterator**
-
-LeafList iterator.
-
-An instance of this class will be returned when iterating a leaf-list.
-
-```python
-LeafListIterator(lst)
-```
-
-Initialize this object.
-
-An instance of this class will be created when iteration of a
-leaf-list starts. Should not be called explicitly.
-
-Members:
-
-set_value(...)
- -Method: - -```python -set_value(self, value) -``` - -Set this leaf-list using a python list. - -
-
-
-
-delete(...)
- -Method: - -```python -delete(self) -``` - -Delete the iterator. - -
-
-
-
-### _class_ **List**
-
-Represents a list node.
-
-A list can be treated mostly like a python dictionary. It supports
-indexing, iteration, the len function, and the in and del operators.
-New items must, however, be created explicitly using the 'create' method.
-
-```python
-List(backend, cs_node, parent=None)
-```
-
-Initialize a List node. Should not be called explicitly.
-
-Members:
-
-next(...)
- -Method: - -```python -next(self) -``` - -Get the next value from the iterator. - -
-
-
-
-create(...)
- -Method: - -```python -create(self, *keys) -``` - -Create and return a new list item with the key '*keys'. - -Arguments can be a single 'maapi.Key' object or one value for each key -in the list. For a keyless oper or in-memory list (eg in action -parameters), no argument should be given. - -Arguments: - -* keys -- item keys (list[str] or maapi.Key ) - -Returns: - -* list item (maagic.ListElement) - -
-
-
-
-delete(...)
- -Method: - -```python -delete(self) -``` - -Delete the entire list. - -
-
-
-
-exists(...)
- -Method: - -```python -exists(self, keys) -``` - -Check if list has an item matching 'keys'. - -Arguments: - -* keys -- item keys (list[str] or maapi.Key ) - -Returns: - -* boolean - -
-
-
-
-filter(...)
- -Method: - -```python -filter(self, xpath_expr=None, secondary_index=None) -``` - -Return a filtered iterator for the list. - -With this method it is possible to filter the selection using an XPath -expression and/or a secondary index. If supported by the data provider, -filtering will be done there. - -Not available for in-memory lists. - -Keyword arguments: - -* xpath_expr -- a valid XPath expression for filtering or None - (string, default: None) (optional) -* secondary_index -- secondary index to use or None - (string, default: None) (optional) - -Returns: - -* iterator (maagic.ListIterator) - -
-
-
-
-keys(...)
- -Method: - -```python -keys(self, xpath_expr=None, secondary_index=None) -``` - -Return all keys in the list. - -Note that this will immediately retrieve every key value from the CDB. -For a long list this could be a time-consuming operation. The keys -selection may be filtered using 'xpath_expr' and 'secondary_index'. - -Not available for in-memory lists. - -Keyword arguments: - -* xpath_expr -- a valid XPath expression for filtering or None - (string, default: None) (optional) -* secondary_index -- secondary index to use or None - (string, default: None) (optional) - -
-
-
-
-### _class_ **ListElement**
-
-Represents a list element.
-
-This is a Container object with a specialized __repr__() method.
-
-```python
-ListElement(backend, cs_node, parent=None, children=None)
-```
-
-Initialize Container node. Should not be called explicitly.
-
-Members:
-
-move(...)
- -Method: - -```python -move(self, key, where, to=None) -``` - -Move the item with key 'key' in an ordered-by user list. - -The destination is given by the arguments 'where' and 'to'. - -Arguments: - -* key -- key of the element that is to be moved (str or maapi.Key) -* where -- one of 'maapi.MOVE_BEFORE', 'maapi.MOVE_AFTER', - 'maapi.MOVE_FIRST', or 'maapi.MOVE_LAST' - -Keyword arguments: - -* to -- key of the destination item for relative moves, only applicable - if 'where' is either 'maapi.MOVE_BEFORE' or 'maapi.MOVE_AFTER'. - -
-
-
-
-### _class_ **ListIterator**
-
-List iterator.
-
-An instance of this class will be returned when iterating a list.
-
-```python
-ListIterator(lst, secondary_index=None, xpath_expr=None)
-```
-
-Initialize this object.
-
-An instance of this class will be created when iteration of a
-list starts. Should not be called explicitly.
-
-Members:
-
-delete(...)
- -Method: - -```python -delete(self) -``` - -Delete the container. - -Deletes all nodes inside the container. The container itself is not -affected as it carries no state of its own. - -Example use: - - root.container.delete() - -
-
-
-
-delete(...)
- -Method: - -```python -delete(self) -``` - -Delete the iterator. - -
-
-
-
-### _class_ **MaagicError**
-
-Exception type used within maagic.
-
-Members:
-
-next(...)
- -Method: - -```python -next(self) -``` - -Get the next value from the iterator. - -
-
-
-
-add_note(...)
- -Method: - -Exception.add_note(note) -- -add a note to the exception - -
-
-
-
-args
- - -
-
-
-
-### _class_ **Node**
-
-Base class of all nodes in the configuration tree.
-
-Contains magic overrides that make children in the YANG tree appear as
-attributes of the Node object and as elements in the list 'self'.
-
-Attributes:
-
-* _name -- the YANG name of this node (str)
-* _path -- the keypath of this node in string form (HKeypathRef)
-* _parent -- the parent of this node, or None if this node
- has no parent (maagic.Node)
-* _cs_node -- the schema node of this node, or None if this node is not in
- the schema (maagic.Node)
-
-```python
-Node(backend, cs_node, parent=None, is_root=False)
-```
-
-Initialize a Node object. Should not be called explicitly.
-
-Members:
-
-_None_
-
-### _class_ **NonEmptyLeaf**
-
-Represents a leaf with a type other than "empty".
-
-```python
-NonEmptyLeaf(backend, cs_node, parent=None)
-```
-
-Initialize a NonEmptyLeaf node. Should not be called explicitly.
-
-Members:
-
-with_traceback(...)
- -Method: - -Exception.with_traceback(tb) -- -set self.__traceback__ to tb and return self. - -
-
-
-
-delete(...)
- -Method: - -```python -delete(self) -``` - -Delete this leaf from the data tree. - -
-
-
-
-exists(...)
- -Method: - -```python -exists(self) -``` - -Check if leaf exists. - -Return True if this leaf exists (has a value) in the data tree. - -
-
-
-
-get_value(...)
- -Method: - -```python -get_value(self) -``` - -Return the value of this leaf. - -The value is returned as the most appropriate python data type. - -
-
-
-
-get_value_object(...)
- -Method: - -```python -get_value_object(self) -``` - -Return the value of this leaf as a Value object. - -
-
-
-
-set_cache(...)
- -Method: - -```python -set_cache(self, value) -``` - -Set the cached value of this leaf without updating the data tree. - -Use of this method is strongly discouraged. - -
-
-
-
-set_value(...)
- -Method: - -```python -set_value(self, value) -``` - -Set the value of this leaf. - -Arguments: - -* value -- the value to be set. If 'value' is not a Value object, - it will be converted to one using Value.str2val. - -
-
-
-
-### _class_ **PresenceContainer**
-
-Represents a presence container.
-
-```python
-PresenceContainer(backend, cs_node, parent=None)
-```
-
-Initialize a PresenceContainer. Should not be called explicitly.
-
-Members:
-
-update_cache(...)
- -Method: - -```python -update_cache(self, force=False) -``` - -Read this leaf's value from the data tree and store it in the cache. - -There is no need to call this method explicitly. - -
-
-
-
-create(...)
- -Method: - -```python -create(self) -``` - -Create and return this presence container in the data tree. - -Example use: - - pc = root.container.presence_container.create() - -
-
-
-
-delete(...)
- -Method: - -```python -delete(self) -``` - -Delete this presence container from the data tree. - -Example use: - - root.container.presence_container.delete() - -
-
-
-
-### _class_ **Root**
-
-Represents the root node in the configuration tree.
-
-The root node is not represented in the schema, it is added for convenience
-and can contain the top level nodes from any number of namespaces as
-children.
-
-```python
-Root(backend=None, namespaces=None)
-```
-
-Initialize a Root node.
-
-Should not be called explicitly. Instead, use the function
-'get_root()'.
-
-Arguments:
-
-* backend -- backend to use, or 'None' for an in-memory tree
- (maapi.Maapi or maapi.Transaction)
-* namespaces -- which namespaces to include in the tree (list)
-
-Members:
-
-_None_
-
-## Predefined Values
-
-```python
-
-NODE_NAME_FULL = 0
-NODE_NAME_PY_FULL = 2
-NODE_NAME_PY_SHORT = 3
-NODE_NAME_SHORT = 1
-```
diff --git a/developer-reference/pyapi/ncs.maapi.md b/developer-reference/pyapi/ncs.maapi.md
deleted file mode 100644
index a355f86f..00000000
--- a/developer-reference/pyapi/ncs.maapi.md
+++ /dev/null
@@ -1,2870 +0,0 @@
-# Python ncs.maapi Module
-
-MAAPI high level module.
-
-This module defines a high level interface to the low-level maapi functions.
-
-The 'Maapi' class encapsulates a MAAPI connection which upon constructing,
-sets up a connection towards ConfD/NCS. An example of setting up a transaction
-and manipulating data:
-
- import ncs
-
- m = ncs.maapi.Maapi()
- m.start_user_session('admin', 'test_context')
- t = m.start_write_trans()
- t.get_elem('/model/data{one}/str')
- t.set_elem('testing', '/model/data{one}/str')
- t.apply()
-
-Another way is to use context managers, which will handle all cleanup
-related to transactions, user sessions and socket connections:
-
- with ncs.maapi.Maapi() as m:
- with ncs.maapi.Session(m, 'admin', 'test_context'):
- with m.start_write_trans() as t:
- t.get_elem('/model/data{one}/str')
- t.set_elem('testing', '/model/data{one}/str')
- t.apply()
-
-Finally, a really compact way of doing this:
-
- with ncs.maapi.single_write_trans('admin', 'test_context') as t:
- t.get_elem('/model/data{one}/str')
- t.set_elem('testing', '/model/data{one}/str')
- t.apply()
-
-## Functions
-
-### connect
-
-```python
-connect(ip='127.0.0.1', port=4569, path=None)
-```
-
-Convenience function for connecting to ConfD/NCS.
-
-The 'ip' and 'port' arguments are ignored if path is specified.
-
-Arguments:
-
-* ip -- ConfD/NCS instance ip address (str)
-* port -- ConfD/NCS instance port (int)
-* path -- ConfD/NCS instance location path (str)
-
-Returns:
-
-* socket (Python socket)
-
-### retry_on_conflict
-
-```python
-retry_on_conflict(retries=10, log=None)
-```
-
-Function/method decorator to retry a transaction in case of conflicts.
-
-When executing multiple concurrent transactions against the NCS RUNNING
-datastore, read-write conflicts are resolved by rejecting transactions
-having potentially stale data with ERR_TRANSACTION_CONFLICT.
-
-This decorator restarts a function, should it run into a conflict, giving
-it multiple attempts to apply. The decorated function must start its own
-transaction because a conflicting transaction must be thrown away entirely
-and a new one started.
-
-Example usage:
-
- @retry_on_conflict()
- def do_work():
- with ncs.maapi.single_write_trans('admin', 'python') as t:
- root = ncs.maagic.get_root(t)
- root.some_value = str(root.some_other_value)
- t.apply()
-
-Arguments:
-
-* retries -- number of times to retry (int)
-* log -- optional log object for logging conflict details
-
-### single_read_trans
-
-```python
-single_read_trans(user, context, groups=[], db=2, ip='127.0.0.1', port=4569, path=None, src_ip='127.0.0.1', src_port=0, proto=1, vendor=None, product=None, version=None, client_id=None, load_schemas=True, flags=0)
-```
-
-Context manager for a single READ transaction.
-
-This function connects to ConfD/NCS, starts a user session and finally
-starts a new READ transaction.
-
-Function signature:
-
- def single_read_trans(user, context, groups=[],
- db=RUNNING, ip=exists(...)
- -Method: - -```python -exists(self) -``` - -Return true if the presence container exists in the data tree. - -Example use: - - root.container.presence_container.exists() - -
-
-
-
-comment(...)
- -Method: - -```python -comment(self, comment) -``` - -Set comment. - -
-
-
-
-commit_queue_async(...)
- -Method: - -```python -commit_queue_async(self) -``` - -Set commit queue asynchronous mode of operation. - -
-
-
-
-commit_queue_atomic(...)
- -Method: - -```python -commit_queue_atomic(self) -``` - -Make the commit queue item atomic. - -
-
-
-
-commit_queue_block_others(...)
- -Method: - -```python -commit_queue_block_others(self) -``` - -Make the commit queue item block other commit queue items for -this device. - -
-
-
-
-commit_queue_bypass(...)
- -Method: - -```python -commit_queue_bypass(self) -``` - -Make the commit transactional even if commit queue is -configured by default. - -
-
-
-
-commit_queue_error_option(...)
- -Method: - -```python -commit_queue_error_option(self, error_option) -``` - -Set commit queue item behaviour on error. - -
-
-
-
-commit_queue_lock(...)
- -Method: - -```python -commit_queue_lock(self) -``` - -Make the commit queue item locked. - -
-
-
-
-commit_queue_non_atomic(...)
- -Method: - -```python -commit_queue_non_atomic(self) -``` - -Make the commit queue item non-atomic. - -
-
-
-
-commit_queue_sync(...)
- -Method: - -```python -commit_queue_sync(self, timeout=None) -``` - -Set commit queue synchronous mode of operation. - -
-
-
-
-commit_queue_tag(...)
- -Method: - -```python -commit_queue_tag(self, tag) -``` - -Set commit-queue tag. Implicitly enabled commit queue commit. - -This function is deprecated and will be removed in a future release. -Use label() instead. - -
-
-
-
-confirm_network_state(...)
- -Method: - -```python -confirm_network_state(self) -``` - -Check that the parts of the device configuration read and/or -modified are up-to-date in CDB before pushing the configuration -change to the device. - -
-
-
-
-confirm_network_state_re_evaluate_policies(...)
- -Method: - -```python -confirm_network_state_re_evaluate_policies(self) -``` - -Check that the parts of the device configuration read and/or -modified are up-to-date in CDB before pushing the configuration -change to the device and re-evaluate policies of effected -services. - -
-
-
-
-dry_run_cli(...)
- -Method: - -```python -dry_run_cli(self) -``` - -Dry-run commit outformat CLI. - -
-
-
-
-dry_run_cli_c(...)
- -Method: - -```python -dry_run_cli_c(self) -``` - -Dry-run commit outformat cli-c. - -
-
-
-
-dry_run_cli_c_reverse(...)
- -Method: - -```python -dry_run_cli_c_reverse(self) -``` - -Dry-run commit outformat cli-c reverse. - -
-
-
-
-dry_run_native(...)
- -Method: - -```python -dry_run_native(self) -``` - -Dry-run commit outformat native. - -
-
-
-
-dry_run_native_reverse(...)
- -Method: - -```python -dry_run_native_reverse(self) -``` - -Dry-run commit outformat native reverse. - -
-
-
-
-dry_run_xml(...)
- -Method: - -```python -dry_run_xml(self) -``` - -Dry-run commit outformat XML. - -
-
-
-
-get_comment(...)
- -Method: - -```python -get_comment(self) -``` - -Get comment. - -
-
-
-
-get_commit_queue_error_option(...)
- -Method: - -```python -get_commit_queue_error_option(self) -``` - -Get commit queue item behaviour on error. - -
-
-
-
-get_commit_queue_sync_timeout(...)
- -Method: - -```python -get_commit_queue_sync_timeout(self) -``` - -Get commit queue synchronous mode of operation timeout. - -
-
-
-
-get_commit_queue_tag(...)
- -Method: - -```python -get_commit_queue_tag(self) -``` - -Get commit-queue tag. - -This function is deprecated and will be removed in a future release. - -
-
-
-
-get_dry_run_outformat(...)
- -Method: - -```python -get_dry_run_outformat(self) -``` - -Get dry-run outformat - -
-
-
-
-get_label(...)
- -Method: - -```python -get_label(self) -``` - -Get label. - -
-
-
-
-get_no_overwrite_scope(...)
- -Method: - -```python -get_no_overwrite_scope(self) -``` - -Get no-overwrite scope - -
-
-
-
-get_trace_id(...)
- -Method: - -```python -get_trace_id(self) -``` - -Get trace id. - -
-
-
-
-is_commit_queue_async(...)
- -Method: - -```python -is_commit_queue_async(self) -``` - -Get commit queue asynchronous mode of operation. - -
-
-
-
-is_commit_queue_atomic(...)
- -Method: - -```python -is_commit_queue_atomic(self) -``` - -Check if the commit queue item should be atomic. - -
-
-
-
-is_commit_queue_block_others(...)
- -Method: - -```python -is_commit_queue_block_others(self) -``` - -Check if the the commit queue item should block other commit -queue items for this device. - -
-
-
-
-is_commit_queue_bypass(...)
- -Method: - -```python -is_commit_queue_bypass(self) -``` - -Check if the commit is transactional even if commit queue is -configured by default. - -
-
-
-
-is_commit_queue_lock(...)
- -Method: - -```python -is_commit_queue_lock(self) -``` - -Check if the commit queue item should be locked. - -
-
-
-
-is_commit_queue_non_atomic(...)
- -Method: - -```python -is_commit_queue_non_atomic(self) -``` - -Check if the commit queue item should be non-atomic. - -
-
-
-
-is_commit_queue_sync(...)
- -Method: - -```python -is_commit_queue_sync(self) -``` - -Get commit queue synchronous mode of operation. - -
-
-
-
-is_confirm_network_state(...)
- -Method: - -```python -is_confirm_network_state(self) -``` - -Should a check be done that the parts of the device configuration -read and/or modified are up-to-date in CDB before pushing the -configuration change to the device. - -
-
-
-
-is_confirm_network_state_re_evaluate_policies(...)
- -Method: - -```python -is_confirm_network_state_re_evaluate_policies(self) -``` - -Is confirm-network-state with re-evaluate-policies enabled. - -
-
-
-
-is_dry_run(...)
- -Method: - -```python -is_dry_run(self) -``` - -Is dry-run enabled - -
-
-
-
-is_dry_run_reverse(...)
- -Method: - -```python -is_dry_run_reverse(self) -``` - -Is dry-run reverse enabled. - -
-
-
-
-is_no_deploy(...)
- -Method: - -```python -is_no_deploy(self) -``` - -Should service create method be invoked or not. - -
-
-
-
-is_no_lsa(...)
- -Method: - -```python -is_no_lsa(self) -``` - -Get no-lsa commit parameter. - -
-
-
-
-is_no_networking(...)
- -Method: - -```python -is_no_networking(self) -``` - -Check if the the configuration should only be written to CDB and -not actually pushed to the device. - -
-
-
-
-is_no_out_of_sync_check(...)
- -Method: - -```python -is_no_out_of_sync_check(self) -``` - -Do not check device sync state before pushing the configuration -change. - -
-
-
-
-is_no_overwrite(...)
- -Method: - -```python -is_no_overwrite(self) -``` - -Should a check be done that the parts of the device configuration -to be modified are up-to-date in CDB before pushing the -configuration change to the device. - -
-
-
-
-is_no_revision_drop(...)
- -Method: - -```python -is_no_revision_drop(self) -``` - -Get no-revision-drop commit parameter. - -
-
-
-
-is_reconcile_attach_non_service_config(...)
- -Method: - -```python -is_reconcile_attach_non_service_config(self) -``` - -Get reconcile commit parameter with attach-non-service-config -behaviour. - -
-
-
-
-is_reconcile_detach_non_service_config(...)
- -Method: - -```python -is_reconcile_detach_non_service_config(self) -``` - -Get reconcile commit parameter with detach-non-service-config -behaviour. - -
-
-
-
-is_reconcile_discard_non_service_config(...)
- -Method: - -```python -is_reconcile_discard_non_service_config(self) -``` - -Get reconcile commit parameter with discard-non-service-config -behaviour. - -
-
-
-
-is_reconcile_keep_non_service_config(...)
- -Method: - -```python -is_reconcile_keep_non_service_config(self) -``` - -Get reconcile commit parameter with keep-non-service-config -behaviour. - -
-
-
-
-is_use_lsa(...)
- -Method: - -```python -is_use_lsa(self) -``` - -Get use-lsa commit parameter. - -
-
-
-
-is_with_service_meta_data(...)
- -Method: - -```python -is_with_service_meta_data(self) -``` - -Get with-service-meta-data commit parameter. - -
-
-
-
-label(...)
- -Method: - -```python -label(self, label) -``` - -Set label. - -
-
-
-
-no_deploy(...)
- -Method: - -```python -no_deploy(self) -``` - -Do not invoke service's create method. - -
-
-
-
-no_lsa(...)
- -Method: - -```python -no_lsa(self) -``` - -Set no-lsa commit parameter. - -
-
-
-
-no_networking(...)
- -Method: - -```python -no_networking(self) -``` - -Only write the configuration to CDB, do not actually push it to -the device. - -
-
-
-
-no_out_of_sync_check(...)
- -Method: - -```python -no_out_of_sync_check(self) -``` - -Do not check device sync state before pushing the configuration -change. - -
-
-
-
-no_overwrite(...)
- -Method: - -```python -no_overwrite(self, scope) -``` - -Check that the parts of the device configuration to be modified -are up-to-date in CDB before pushing the configuration change to the -device. - -
-
-
-
-no_revision_drop(...)
- -Method: - -```python -no_revision_drop(self) -``` - -Set no-revision-drop commit parameter. - -
-
-
-
-reconcile_attach_non_service_config(...)
- -Method: - -```python -reconcile_attach_non_service_config(self) -``` - -Set reconcile commit parameter with attach-non-service-config -behaviour. - -
-
-
-
-reconcile_detach_non_service_config(...)
- -Method: - -```python -reconcile_detach_non_service_config(self) -``` - -Set reconcile commit parameter with detach-non-service-config -behaviour. - -
-
-
-
-reconcile_discard_non_service_config(...)
- -Method: - -```python -reconcile_discard_non_service_config(self) -``` - -Set reconcile commit parameter with discard-non-service-config -behaviour. - -
-
-
-
-reconcile_keep_non_service_config(...)
- -Method: - -```python -reconcile_keep_non_service_config(self) -``` - -Set reconcile commit parameter with keep-non-service-config -behaviour. - -
-
-
-
-set_dry_run_outformat(...)
- -Method: - -```python -set_dry_run_outformat(self, outformat) -``` - -Set dry-run outformat - -
-
-
-
-trace_id(...)
- -Method: - -```python -trace_id(self, trace_id) -``` - -Set trace id. - -
-
-
-
-use_lsa(...)
- -Method: - -```python -use_lsa(self) -``` - -Set use-lsa commit parameter. - -
-
-
-
-### _class_ **DryRunOutformat**
-
-Enumeration for dry run formats:
-XML = 1
-CLI = 2
-NATIVE = 3
-CLI_C = 4
-
-```python
-DryRunOutformat(*values)
-```
-
-Members:
-
-with_service_meta_data(...)
- -Method: - -```python -with_service_meta_data(self) -``` - -Set with-service-meta-data commit parameter. - -
-
-
-
-CLI
- -```python -CLI = 2 -``` - - -
-
-
-
-CLI_C
- -```python -CLI_C = 4 -``` - - -
-
-
-
-NATIVE
- -```python -NATIVE = 3 -``` - - -
-
-
-
-XML
- -```python -XML = 1 -``` - - -
-
-
-
-name
- -The name of the Enum member. - -
-
-
-
-### _class_ **Key**
-
-Key string encapsulation and helper.
-
-```python
-Key(key, enum_cs_nodes=None)
-```
-
-Initialize a key.
-
-'key' may be a string or a list of strings.
-
-Members:
-
-_None_
-
-### _class_ **Maapi**
-
-Class encapsulating a MAAPI connection.
-
-```python
-Maapi(ip='127.0.0.1', port=4569, path=None, load_schemas=True, msock=None)
-```
-
-Create a Maapi instance.
-
-Arguments:
-
-* ip -- ConfD/NCS instance ip address (str, optional)
-* port -- ConfD/NCS instance port (int, optional)
-* path -- ConfD/NCS instance location path (str, optional)
-* msock -- already connected MAAPI socket (socket.socket, optional)
- (ip, port and path ignored)
-* load_schemas -- whether schemas should be loaded/reloaded or not
- LOAD_SCHEMAS_LOAD = load schemas unless already loaded
- LOAD_SCHEMAS_SKIP = do not load schemas
- LOAD_SCHEMAS_RELOAD = force reload of schemas
-
-The option LOAD_SCHEMAS_RELOAD can be used to force a reload of
-schemas, for example when connecting to a different ConfD/NSO node.
-Note that previously constructed maagic objects will be invalid and
-using them will lead to undefined behavior. Use this option with care,
-for example in a small script querying a list of running nodes.
-
-Members:
-
-value
- -The value of the Enum member. - -
-
-
-
-apply_template(...)
- -Method: - -```python -apply_template(self, th, name, path, vars=None, flags=0) -``` - -Apply a template. - -
-
-
-
-attach(...)
- -Method: - -```python -attach(self, ctx_or_th, hashed_ns=0, usid=0) -``` - -Attach to an existing transaction. - -'ctx_or_th' may be either a TransCtxRef or a transaction handle. -The 'hashed_ns' argument is basically just there to save a call to -set_namespace(). 'usid' is only used if 'ctx_or_th' is a transaction -handle and if set to 0 the user session id that is the owner of the -transaction will be used. - -Arguments: - -* ctx_or_th (TransCtxRef or transaction handle) -* hashed_ns (int) -* usid (int) - -Returns: - -* transaction object (maapi.Transaction) - -
-
-
-
-attach_init(...)
- -Method: - -```python -attach_init(self) -``` - -Attach to phase0 for CDB initialization and upgrade. - -
-
-
-
-authenticate(...)
- -Method: - -```python -authenticate(self, user, password, n, src_addr=None, src_port=None, context=None, prot=None) -``` - -Authenticate a user using the AAA configuration. - -Use src_addr, src_port, context and prot to use an external -authentication executable. -Use the 'n' to get a list of n-1 groups that the user is a member of. -Use n=1 if the function is used in a context where the group names -are not needed. - -Returns 1 if accepted without groups. If the authentication failed -or was accepted a tuple with first element status code, 0 for -rejection and 1 for accepted is returned. The second element either -contains the reason for the rejection as a string OR a list groupnames. - -Arguments: - -* user - username (str) -* password - passwor d (str) -* n - number of groups to return (int) -* src_addr - source ip address (str) -* src_port - source port (int) -* context - context for the session (str) -* prot - protocol used by the client for connecting (int) - -Returns: - -* status (int or tuple) - -
-
-
-
-close(...)
- -Method: - -```python -close(self) -``` - -Ends session and closes socket. - -
-
-
-
-cursor(...)
- -Method: - -```python -cursor(self, th, path, enum_cs_nodes=None, want_values=False, secondary_index=None, xpath_expr=None) -``` - -Get an iterable list cursor. - -
-
-
-
-destroy_cursor(...)
- -Method: - -```python -destroy_cursor(self, mc) -``` - -Destroy cursor. - -Arguments: - -* cursor (maapi.Cursor) - -
-
-
-
-detach(...)
- -Method: - -```python -detach(self, ctx_or_th) -``` - -Detach the underlying MAAPI socket. - -Arguments: - -* ctx_or_th (TransCtxRef or transaction handle) - -
-
-
-
-do_display(...)
- -Method: - -```python -do_display(self, th, path) -``` - -Do display. - -If the data model uses the YANG when or tailf:display-when -statement, this function can be used to determine if the item -given by the path should be displayed or not. - -Arguments: - -* th -- transaction handle -* path -- path to the 'display-when' statement (str) - -Returns - -* boolean - -
-
-
-
-end_progress_span(...)
- -Method: - -```python -end_progress_span(self, *args) -``` - -Don't call this function. - -Call instance.end() on the progress.Span instance created from -start_progress_span() instead. - -
-
-
-
-exists(...)
- -Method: - -```python -exists(self, th, path) -``` - -Check if path exists. - -Arguments: - -* th -- transaction handle -* path -- path to the node in the data tree (str) - -Returns: - -* boolean - -
-
-
-
-find_next(...)
- -Method: - -```python -find_next(self, mc, type, inkeys) -``` - -Find next. - -Update the cursor 'mc' with the key(s) for the list entry designated -by the 'type' and 'inkeys' arguments. This function may be used to -start a traversal from an arbitrary entry in a list. Keys for -subsequent entries may be retrieved with the get_next() function. -When no more keys are found, False is returned. - -The strategy to use is defined by 'type': - - FIND_NEXT - The keys for the first list entry after the one - indicated by the 'inkeys' argument. - FIND_SAME_OR_NEXT - If the values in the 'inkeys' array completely - identifies an actual existing list entry, the keys for - this entry are requested. Otherwise the same logic as - for FIND_NEXT above. - -
-
-
-
-get_next(...)
- -Method: - -```python -get_next(self, mc) -``` - -Iterate and get the keys for the next entry in a list. - -When no more keys are found, False is returned - -Arguments: - -* cursor (maapi.Cursor) - -Returns: - -* keys (list or boolean) - -
-
-
-
-get_objects(...)
- -Method: - -```python -get_objects(self, mc, n, nobj) -``` - -Get objects. - -Read at most n values from each nobj lists starting at cursor mc. -Returns a list of Value's. - -Arguments: - -* mc (maapi.Cursor) -* n -- at most n values will be read (int) -* nobj -- number of nobj lists which n elements will be taken from (int) - -Returns: - -* list of values (list) - -
-
-
-
-get_running_db_status(...)
- -Method: - -```python -get_running_db_status(self) -``` - -Get running db status. - -Gets the status of the running db. Returns True if consistent and -False otherwise. - -Returns: - -* boolean - -
-
-
-
-ip
- -_Readonly property_ - -Return address to connect to the IPC port - -
-
-
-
-load_schemas(...)
- -Method: - -```python -load_schemas(self, use_maapi_socket=False) -``` - -Load the schemas to Python (using shared memory if enabled). - -If 'use_maapi_socket' is set to True, the schmeas are loaded through -the NSO daemon via a MAAPI socket. - -
-
-
-
-netconf_ssh_call_home(...)
- -Method: - -```python -netconf_ssh_call_home(self, host, port=4334) -``` - -Initiate NETCONF SSH Call Home. - -
-
-
-
-netconf_ssh_call_home_opaque(...)
- -Method: - -```python -netconf_ssh_call_home_opaque(self, host, opaque, port=4334) -``` - -Initiate NETCONF SSH Call Home w. opaque data. - -
-
-
-
-path
- -_Readonly property_ - -Return path to connect to the IPC port - -
-
-
-
-port
- -_Readonly property_ - -Return port to connect to the IPC port - -
-
-
-
-progress_info(...)
- -Method: - -```python -progress_info(self, msg, verbosity=0, attrs=None, links=None, path=None) -``` - -While spans represents a pair of data points: start and stop; info -events are instead singular events, one point in time. Call -progress_info() to write a progress span info event to the progress -trace. The info event will have the same span-id as the start and stop -events of the currently ongoing progress span in the active user session -or transaction. See help for start_progress_span() for more information. - -Arguments: - -* msg - message to report (str) -* verbosity - ncs.VERBOSITY_*, VERBOSITY_NORMAL is default (optional) -* attrs - user defined attributes (optional) -* links - list of ncs.progress.Span or dict (optional) -* path - keypath to an action/leaf/service/etc (str, optional) - -
-
-
-
-query_free_result(...)
- -Method: - -```python -query_free_result(self, qrs) -``` - -Deallocate QueryResult memory. - -Deallocated memory inside the QueryResult object 'qrs' returned from -query_result(). It is not necessary to call this method as deallocation -will be done when the Python library garbage collects the QueryResult -object. - -Arguments: - -* qrs -- the query result structure to free - -
-
-
-
-report_progress(...)
- -Method: - -```python -report_progress(self, th, verbosity, msg, package=None) -``` - -Report transaction/action progress. - -The 'package' argument is only available to NCS. - -This function is deprecated and will be removed in a future release. -Use progress_info() instead. - -
-
-
-
-report_progress_start(...)
- -Method: - -```python -report_progress_start(self, th, verbosity, msg, package=None) -``` - -Report transaction/action progress. - -Used for calculation of the duration between two events. The method -returns a _Progress object to be passed to report_progress_stop() -once the event has finished. - -The 'package' argument is only available to NCS. - -This function is deprecated and will be removed in a future release. -Use start_progress_span() instead. - -
-
-
-
-report_progress_stop(...)
- -Method: - -```python -report_progress_stop(self, th, progress, annotation=None) -``` - -Report transaction/action progress. - -Used for calculation of the duration between two events. The method -takes a _Progress object returned from report_progress_start(). - -This function is deprecated and will be removed in a future release. -Use end_progress_span() instead. - -
-
-
-
-report_service_progress(...)
- -Method: - -```python -report_service_progress(self, th, verbosity, msg, path, package=None) -``` - -Report transaction progress for a FASTMAP service. - -This function is deprecated and will be removed in a future release. -Use progress_info() instead. - -
-
-
-
-report_service_progress_start(...)
- -Method: - -```python -report_service_progress_start(self, th, verbosity, msg, path, package=None) -``` - -Report transaction progress for a FASTMAP service. - -Used for calculation of the duration between two events. The method -returns a _Progress object to be passed to -report_service_progress_stop() once the event has finished. - -This function is deprecated and will be removed in a future release. -Use start_progress_span() instead. - -
-
-
-
-report_service_progress_stop(...)
- -Method: - -```python -report_service_progress_stop(self, th, progress, annotation=None) -``` - -Report transaction progress for a FASTMAP service. - -Used for calculation of the duration between two events. The method -takes a _Progress object returned from report_service_progress_start(). - -This function is deprecated and will be removed in a future release. -Use end_progress_span() instead. - -
-
-
-
-run_with_retry(...)
- -Method: - -```python -run_with_retry(self, fun, max_num_retries=10, commit_params=None, usid=0, flags=0, vendor=None, product=None, version=None, client_id=None) -``` - -Run fun with a new read-write transaction against RUNNING. - -The transaction is applied if fun returns True. The fun is -only retried in case of transaction conflicts. Each retry is -run using a new transaction. - -The last conflict error.Error is thrown in case of max number of -retries is reached. - -Arguments: - -* fun - work fun (fun(maapi.Transaction) -> bool) -* usid - user id (int) -* max_num_retries - maximum number of retries (int) - -Returns: - -* bool True if transation was applied, else False. - -
-
-
-
-safe_create(...)
- -Method: - -```python -safe_create(self, th, path) -``` - -Safe version of create. - -Create a new list entry, a presence container, or a leaf of -type empty in the data tree - if it doesn't already exist. - -Arguments: - -* th -- transaction handle -* path -- path to the new element (str) - -
-
-
-
-safe_delete(...)
- -Method: - -```python -safe_delete(self, th, path) -``` - -Safe version of delete. - -Delete an existing list entry, a presence container, or an -optional leaf and all its children (if any) from the data -tree. If it exists. - -Arguments: - -* th -- transaction handle -* path -- path to the element (str) - -
-
-
-
-safe_get_elem(...)
- -Method: - -```python -safe_get_elem(self, th, path) -``` - -Safe version of get_elem. - -Read the element at 'path', returns 'None' if it doesn't -exist. - -Arguments: - -* th -- transaction handle -* path -- path to the element (str) - -Returns: - -* configuration element - -
-
-
-
-safe_get_object(...)
- -Method: - -```python -safe_get_object(self, th, n, path) -``` - -Safe version of get_object. - -This function reads at most 'n' values from the list entry or -container specified by the 'path'. Returns 'None' the path is -empty. - -Arguments: - -* th -- transaction handle -* n -- at most n values (int) -* path -- path to the object (str) - -Returns: - -* configuration object - -
-
-
-
-set_elem(...)
- -Method: - -```python -set_elem(self, th, value, path) -``` - -Set the node at 'path' to 'value'. - -If 'value' is not of type Value it will be converted to a string -before calling set_elem2() under the hood. - -Arguments: - -* th -- transaction handle -* value -- element value (Value or str) -* path -- path to the element (str) - -
-
-
-
-shared_apply_template(...)
- -Method: - -```python -shared_apply_template(self, th, name, path, vars=None, flags=0) -``` - -FASTMAP version of apply_template(). - -
-
-
-
-shared_copy_tree(...)
- -Method: - -```python -shared_copy_tree(self, th, from_path, to_path, flags=0) -``` - -FASTMAP version of copy_tree(). - -
-
-
-
-shared_create(...)
- -Method: - -```python -shared_create(self, th, path, flags=0) -``` - -FASTMAP version of create(). - -
-
-
-
-shared_insert(...)
- -Method: - -```python -shared_insert(self, th, path, flags=0) -``` - -FASTMAP version of insert(). - -
-
-
-
-shared_set_elem(...)
- -Method: - -```python -shared_set_elem(self, th, value, path, flags=0) -``` - -FASTMAP version of set_elem(). - -If 'value' is not of type Value it will be converted to a string -before calling shared_set_elem2() under the hood. - -
-
-
-
-shared_set_values(...)
- -Method: - -```python -shared_set_values(self, th, values, path, flags=0) -``` - -FASTMAP version of set_values(). - -
-
-
-
-start_progress_span(...)
- -Method: - -```python -start_progress_span(self, msg, verbosity=0, attrs=None, links=None, path=None) -``` - -Starts a progress span. Progress spans are trace messages written to -the progress trace and the developer log. A progress span consists of a -start and a stop event which can be used to calculate the duration -between the two. Those events can be identified with unique span-ids. -Inside the span it is possible to start new spans, which will then -become child spans, the parent-span-id is set to the previous spans' -span-id. A child span can be used to calculate the duration of a sub -task, and is started from consecutive maapi_start_progress_span() calls, -and is ended with maapi_end_progress_span(). - -The concepts of traces, trace-id and spans are highly influenced by -https://opentelemetry.io/docs/concepts/signals/traces/#spans - - -Call help(ncs.progress) or help(confd.progress) for examples. - -Arguments: - -* msg - message to report (str) -* verbosity - ncs.VERBOSITY_*, VERBOSITY_NORMAL is default (optional) -* attrs - user defined attributes (optional) -* links - list of ncs.progress.Span or dict (optional) -* path - keypath to an action/leaf/service/etc (str, optional) - -Returns: - -* trace span (ncs.progress.Span) - -
-
-
-
-start_read_trans(...)
- -Method: - -```python -start_read_trans(self, db=2, usid=0, flags=0, vendor=None, product=None, version=None, client_id=None) -``` - -Start a read transaction. - -For details see start_trans(). - -
-
-
-
-start_trans(...)
- -Method: - -```python -start_trans(self, rw, db=2, usid=0, flags=0, vendor=None, product=None, version=None, client_id=None) -``` - -Start a transaction towards the 'db'. - -This function starts a new a new transaction towards the given -data store. - -Arguments: - -* rw -- Either READ or READ_WRITE flag (ncs) -* db -- Either CANDIDATE, RUNNING or STARTUP flag (cdb) -* usid -- user id (int) -* flags -- additional transaction flags (int) -* vendor -- lock error information (str, optional) -* product -- lock error information (str, optional) -* version -- lock error information (str, optional) -* client_id -- lock error information (str, optional) - -Returns: - -* transaction (maapi.Transaction) - -Flags (maapi): - -* FLAG_HINT_BULK -* FLAG_NO_DEFAULTS -* FLAG_CONFIG_ONLY -* FLAG_HIDE_INACTIVE -* FLAG_DELAYED_WHEN -* FLAG_NO_CONFIG_CACHE -* FLAG_CONFIG_CACHE_ONLY -* FLAG_HIDE_ALL_HIDEGROUPS -* FLAG_SKIP_SUBSCRIBERS - -
-
-
-
-start_trans_in_trans(...)
- -Method: - -```python -start_trans_in_trans(self, th, readwrite, usid=0) -``` - -Start a new transaction within a transaction. - -This function makes it possible to start a transaction with another -transaction as backend, instead of an actual data store. This can be -useful if we want to make a set of related changes, and then either -apply or discard them all based on some criterion, while other changes -remain unaffected. The thandle identifies the backend transaction to -use. If 'usid' is 0, the transaction will be started within the user -session associated with the MAAPI socket, otherwise it will be started -within the user session given by usid. If we call apply() on this -"transaction in a transaction" object, the changes (if any) will be -applied to the backend transaction. To discard the changes, call -finish() without calling apply() first. - -Arguments: - -* th -- transaction handle -* readwrite -- Either READ or READ_WRITE flag (ncs) -* usid -- user id (int) - -Returns: - -* transaction (maapi.Transaction) - -
-
-
-
-start_user_session(...)
- -Method: - -```python -start_user_session(self, user, context, groups=[], src_ip='127.0.0.1', src_port=0, proto=1, vendor=None, product=None, version=None, client_id=None, path=None) -``` - -Start a new user session. - -This method gives some resonable defaults. - -Arguments: - -* user - username (str) -* context - context for the session (str) -* groups - groups (list) -* src_ip - source ip address (str) -* src_port - source port (int) -* proto - protocol used by for connecting (i.e. ncs.PROTO_TCP) -* vendor -- lock error information (str, optional) -* product -- lock error information (str, optional) -* version -- lock error information (str, optional) -* client_id -- lock error information (str, optional) -* path -- path to Unix-domain socket (only for NSO) - -Protocol flags (ncs): - -* PROTO_CONSOLE -* PROTO_HTTP -* PROTO_HTTPS -* PROTO_SSH -* PROTO_SSL -* PROTO_SYSTEM -* PROTO_TCP -* PROTO_TLS -* PROTO_TRACE -* PROTO_UDP - -Example use: - - maapi.start_user_session( - sock_maapi, - 'admin', - 'python', - [], - _ncs.ADDR, - _ncs.PROTO_TCP) - -
-
-
-
-start_write_trans(...)
- -Method: - -```python -start_write_trans(self, db=2, usid=0, flags=0, vendor=None, product=None, version=None, client_id=None) -``` - -Start a write transaction. - -For details see start_trans(). - -
-
-
-
-### _class_ **NoOverwriteScope**
-
-Enumeration for no-overwrite scopes:
-WRITE_SET_ONLY = 1
-WRITE_AND_FULL_READ_SET = 2
-WRITE_AND_SERVICE_READ_SET = 3
-
-```python
-NoOverwriteScope(*values)
-```
-
-Members:
-
-write_service_log_entry(...)
- -Method: - -```python -write_service_log_entry(self, path, msg, type, level) -``` - -Write service log entries. - -This function makes it possible to write service log entries from -FASTMAP code. - -
-
-
-
-WRITE_AND_FULL_READ_SET
- -```python -WRITE_AND_FULL_READ_SET = 2 -``` - - -
-
-
-
-WRITE_AND_SERVICE_READ_SET
- -```python -WRITE_AND_SERVICE_READ_SET = 3 -``` - - -
-
-
-
-WRITE_SET_ONLY
- -```python -WRITE_SET_ONLY = 1 -``` - - -
-
-
-
-name
- -The name of the Enum member. - -
-
-
-
-### _class_ **Session**
-
-Encapsulate a MAAPI user session.
-
-Context manager for user sessions. This class makes it easy to use
-a single Maapi connection and switch user session along the way.
-For example:
-
- with Maapi() as m:
- for user, context, device in devlist:
- with Session(m, user, context):
- with m.start_write_trans() as t:
- # ...
- # do something using the correct user session
- # ...
- t.apply()
-
-```python
-Session(maapi, user, context, groups=[], src_ip='127.0.0.1', src_port=0, proto=1, vendor=None, product=None, version=None, client_id=None, path=None)
-```
-
-Initialize a Session object via start_user_session().
-
-Arguments:
-
-* maapi -- maapi object (maapi.Maapi)
-* for all other arguments see start_user_session()
-
-Members:
-
-value
- -The value of the Enum member. - -
-
-
-
-### _class_ **Transaction**
-
-Class that corresponds to a single MAAPI transaction.
-
-```python
-Transaction(maapi, th=None, rw=None, db=2, vendor=None, product=None, version=None, client_id=None)
-```
-
-Initialize a Transaction object.
-
-When created one may access the maapi and th arguments like this:
-
- trans = Transaction(mymaapi, th=myth)
- trans.maapi # the Maapi object
- trans.th # the transaction handle
-
-An instance of this class is also a context manager:
-
- with Transaction(mymaapi, th=myth) as trans:
- # do something here...
-
-When exiting the with statement, finish() will be called.
-
-If 'th' is left out (or None) a new transaction is started using
-the 'db' and 'rw' arguments, otherwise 'db' and 'rw' are ignored.
-
-Arguments:
-
-* maapi -- a Maapi object (maapi.Maapi)
-* th -- a transaction handle or None
-* rw -- Either READ or READ_WRITE flag (ncs)
-* db -- Either CANDIDATE, RUNNING or STARTUP flag (cdb)
-* vendor -- lock error information (optional)
-* product -- lock error information (optional)
-* version -- lock error information (optional)
-* client_id -- lock error information (optional)
-
-Members:
-
-close(...)
- -Method: - -```python -close(self) -``` - -Close the user session. - -
-
-
-
-abort(...)
- -Method: - -```python -abort(self) -``` - -Abort the transaction. - -
-
-
-
-apply(...)
- -Method: - -```python -apply(self, keep_open=True, flags=0) -``` - -Apply the transaction. - -Validates, prepares and eventually commits or aborts the -transaction. If the validation fails and the 'keep_open' -argument is set to True (default), the transaction is left -open and the developer can react upon the validation errors. - -Arguments: - -* keep_open -- keep transaction open (boolean) -* flags - additional transaction flags (int) - -Flags (maapi): - -* COMMIT_NCS_NO_REVISION_DROP -* COMMIT_NCS_NO_DEPLOY -* COMMIT_NCS_NO_NETWORKING -* COMMIT_NCS_NO_OUT_OF_SYNC_CHECK -* COMMIT_NCS_NO_OVERWRITE_WRITE_SET_ONLY -* COMMIT_NCS_NO_OVERWRITE_WRITE_AND_FULL_READ_SET -* COMMIT_NCS_NO_OVERWRITE_WRITE_AND_FULL_SERVICE_SET -* COMMIT_NCS_USE_LSA -* COMMIT_NCS_NO_LSA -* COMMIT_NCS_RECONCILE_KEEP_NON_SERVICE_CONFIG -* COMMIT_NCS_RECONCILE_DISCARD_NON_SERVICE_CONFIG -* COMMIT_NCS_RECONCILE_ATTACH_NON_SERVICE_CONFIG -* COMMIT_NCS_RECONCILE_DETACH_NON_SERVICE_CONFIG -* COMMIT_NCS_CONFIRM_NETWORK_STATE -* COMMIT_NCS_CONFIRM_NETWORK_STATE_RE_EVALUATE_POLICIES - -
-
-
-
-apply_params(...)
- -Method: - -```python -apply_params(self, keep_open=True, params=None) -``` - -Apply the transaction and return the result in form of dict(). - -Validates, prepares and eventually commits or aborts the -transaction. If the validation fails and the 'keep_open' -argument is set to True (default), the transaction is left -open and the developer can react upon the validation errors. - -The 'params' argument represent commit parameters. See CommitParams -class for available commit parameters. - -The result is a dictionary representing the result of applying -transaction. If dry-run was requested, then the resulting dictionary -will have 'dry-run' key set along with the actual results. If commit -through commit queue was requested, then the resulting dictionary -will have 'commit-queue' key set. Otherwise the dictionary will -be empty. - -Arguments: - -* keep_open -- keep transaction open (boolean) -* params -- list of commit parameters (maapi.CommitParams) - -Returns: - -* dict (see above) - -Example use: - - with ncs.maapi.single_write_trans('admin', 'python') as t: - root = ncs.maagic.get_root(t) - dns_list = root.devices.device['ex1'].config.sys.dns.server - dns_list.create('192.0.2.1') - params = t.get_params() - params.dry_run_native() - result = t.apply_params(True, params) - print(result['device']['ex1']) - t.apply_params(True, t.get_params()) - -
-
-
-
-commit(...)
- -Method: - -```python -commit(self) -``` - -Commit the transaction. - -
-
-
-
-end_progress_span(...)
- -Method: - -```python -end_progress_span(self, *args) -``` - -Don't call this function. - -Call instance.end() on the progress.Span instance created from -start_progress_span() instead. - -
-
-
-
-finish(...)
- -Method: - -```python -finish(self) -``` - -Finish the transaction. - -This will finish the transaction. If the transaction is implemented -by an external database, this will invoke the finish() callback. - -
-
-
-
-get_params(...)
- -Method: - -```python -get_params(self) -``` - -Get the current commit parameters for the transaction. - -The result is an instance of the CommitParams class. - -
-
-
-
-hide_group(...)
- -Method: - -```python -hide_group(self, group_name) -``` - -Do hide a hide group. - -Hide all nodes belonging to a hide group in a transaction that started -with flag FLAG_HIDE_ALL_HIDEGROUPS. - -
-
-
-
-prepare(...)
- -Method: - -```python -prepare(self, flags=0) -``` - -Prepare transaction. - -This function must be called as first part of two-phase commit. After -this function has been called, commit() or abort() must be called. - -It will invoke the prepare callback in all participants in the -transaction. If all participants reply with OK, the second phase of -the two-phase commit procedure is commenced. - -Arguments: - -* flags - additional transaction flags (int) - -Flags (maapi): - -* COMMIT_NCS_NO_REVISION_DROP -* COMMIT_NCS_NO_DEPLOY -* COMMIT_NCS_NO_NETWORKING -* COMMIT_NCS_NO_OUT_OF_SYNC_CHECK -* COMMIT_NCS_NO_OVERWRITE_WRITE_SET_ONLY -* COMMIT_NCS_NO_OVERWRITE_WRITE_AND_FULL_READ_SET -* COMMIT_NCS_NO_OVERWRITE_WRITE_AND_SERVICE_READ_SET -* COMMIT_NCS_USE_LSA -* COMMIT_NCS_NO_LSA -* COMMIT_NCS_RECONCILE_KEEP_NON_SERVICE_CONFIG -* COMMIT_NCS_RECONCILE_DISCARD_NON_SERVICE_CONFIG -* COMMIT_NCS_RECONCILE_ATTACH_NON_SERVICE_CONFIG -* COMMIT_NCS_RECONCILE_DETACH_NON_SERVICE_CONFIG -* COMMIT_NCS_CONFIRM_NETWORK_STATE -* COMMIT_NCS_CONFIRM_NETWORK_STATE_RE_EVALUATE_POLICIES - -
-
-
-
-progress_info(...)
- -Method: - -```python -progress_info(self, msg, verbosity=0, attrs=None, links=None, path=None) -``` - -While spans represents a pair of data points: start and stop; info -events are instead singular events, one point in time. Call -progress_info() to write a progress span info event to the progress -trace. The info event will have the same span-id as the start and stop -events of the currently ongoing progress span in the active user session -or transaction. See help for start_progress_span() for more information. - -Arguments: - -* msg - message to report (str) -* verbosity - ncs.VERBOSITY_*, VERBOSITY_NORMAL is default (optional) -* attrs - user defined attributes (optional) -* links - list of ncs.progress.Span or dict (optional) -* path - keypath to an action/leaf/service/etc (str, optional) - -
-
-
-
-start_progress_span(...)
- -Method: - -```python -start_progress_span(self, msg, verbosity=0, attrs=None, links=None, path=None) -``` - -Starts a progress span. Progress spans are trace messages written to -the progress trace and the developer log. A progress span consists of a -start and a stop event which can be used to calculate the duration -between the two. Those events can be identified with unique span-id. -Inside the span it is possible to start new spans, which will then -become child spans, the parent-span-id is set to the previous spans' -span-id. A child span can be used to calculate the duration of a sub -task, and is started from consecutive maapi_start_progress_span() calls, -and is ended with maapi_end_progress_span(). - -The function returns a Span object which either stops the span by -invoking span.end() or by exiting a 'with' context. Messages are -written to the progress trace which can be directed to a file, oper -data or as notifications. - -Call help(ncs.progress) or help(confd.progress) for examples. - -Arguments: - -* msg - message to report (str) -* verbosity - ncs.VERBOSITY_*, VERBOSITY_NORMAL is default (optional) -* attrs - user defined attributes (optional) -* links - list of ncs.progress.Span or dict (optional) -* path - keypath to an action/leaf/service/etc (str, optional) - -Returns: - -* trace span (ncs.progress.Span) - -
-
-
-
-unhide_group(...)
- -Method: - -```python -unhide_group(self, group_name) -``` - -Do unhide a hide group. - -Unhide all nodes belonging to a hide group in a transaction that started -with flag FLAG_HIDE_ALL_HIDEGROUPS. - -
-
-
-
-## Predefined Values
-
-```python
-
-CMD_KEEP_PIPE = 8
-CMD_NO_AAA = 4
-CMD_NO_FULLPATH = 1
-CMD_NO_HIDDEN = 2
-COMMIT_NCS_ASYNC_COMMIT_QUEUE = 256
-COMMIT_NCS_BYPASS_COMMIT_QUEUE = 64
-COMMIT_NCS_CONFIRM_NETWORK_STATE = 268435456
-COMMIT_NCS_CONFIRM_NETWORK_STATE_RE_EVALUATE_POLICIES = 536870912
-COMMIT_NCS_NO_DEPLOY = 8
-COMMIT_NCS_NO_FASTMAP = 8
-COMMIT_NCS_NO_LSA = 1048576
-COMMIT_NCS_NO_NETWORKING = 16
-COMMIT_NCS_NO_OUT_OF_SYNC_CHECK = 32
-COMMIT_NCS_NO_OVERWRITE = 1024
-COMMIT_NCS_NO_REVISION_DROP = 4
-COMMIT_NCS_RECONCILE_ATTACH_NON_SERVICE_CONFIG = 67108864
-COMMIT_NCS_RECONCILE_DETACH_NON_SERVICE_CONFIG = 134217728
-COMMIT_NCS_RECONCILE_DISCARD_NON_SERVICE_CONFIG = 33554432
-COMMIT_NCS_RECONCILE_KEEP_NON_SERVICE_CONFIG = 16777216
-COMMIT_NCS_SYNC_COMMIT_QUEUE = 512
-COMMIT_NCS_USE_LSA = 524288
-CONFIG_AUTOCOMMIT = 8192
-CONFIG_C = 4
-CONFIG_CDB_ONLY = 4194304
-CONFIG_CONTINUE_ON_ERROR = 16384
-CONFIG_C_IOS = 32
-CONFIG_HIDE_ALL = 2048
-CONFIG_J = 2
-CONFIG_JSON = 131072
-CONFIG_MERGE = 64
-CONFIG_NO_BACKQUOTE = 2097152
-CONFIG_NO_PARENTS = 524288
-CONFIG_OPER_ONLY = 1048576
-CONFIG_READ_WRITE_ACCESS_ONLY = 33554432
-CONFIG_REPLACE = 1024
-CONFIG_SHOW_DEFAULTS = 16
-CONFIG_SUPPRESS_ERRORS = 32768
-CONFIG_TURBO_C = 8388608
-CONFIG_UNHIDE_ALL = 4096
-CONFIG_WITH_DEFAULTS = 8
-CONFIG_WITH_OPER = 128
-CONFIG_WITH_SERVICE_META = 262144
-CONFIG_XML = 1
-CONFIG_XML_LOAD_LAX = 65536
-CONFIG_XML_PRETTY = 512
-CONFIG_XPATH = 256
-DEL_ALL = 2
-DEL_EXPORTED = 3
-DEL_SAFE = 1
-ECHO = 1
-FLAG_CONFIG_CACHE_ONLY = 32
-FLAG_CONFIG_ONLY = 4
-FLAG_DELAYED_WHEN = 64
-FLAG_DELETE = 2
-FLAG_EMIT_PARENTS = 1
-FLAG_HIDE_ALL_HIDEGROUPS = 256
-FLAG_HIDE_INACTIVE = 8
-FLAG_HINT_BULK = 1
-FLAG_NON_RECURSIVE = 4
-FLAG_NO_CONFIG_CACHE = 16
-FLAG_NO_DEFAULTS = 2
-FLAG_SKIP_SUBSCRIBERS = 512
-LOAD_SCHEMAS_LOAD = True
-LOAD_SCHEMAS_RELOAD = 2
-LOAD_SCHEMAS_SKIP = False
-MOVE_AFTER = 3
-MOVE_BEFORE = 2
-MOVE_FIRST = 1
-MOVE_LAST = 4
-NOECHO = 0
-PRODUCT = 'NCS'
-UPGRADE_KILL_ON_TIMEOUT = 1
-```
diff --git a/developer-reference/pyapi/ncs.md b/developer-reference/pyapi/ncs.md
deleted file mode 100644
index 81e4b1b5..00000000
--- a/developer-reference/pyapi/ncs.md
+++ /dev/null
@@ -1,367 +0,0 @@
-# Python ncs Module
-
-NCS Python high level module.
-
-The high-level APIs provided by this module are an abstraction on top of the
-low-level APIs. This makes them easier to use, improves code readability and
-development rate for common use cases, such as service and action callbacks.
-
-As an example, the maagic module greatly simplifies the way of accessing data.
-First it helps in navigating the data model, using standard Python object dot
-notation, giving very clear and readable code. The context handlers remove the
-need to close sockets, user sessions and transactions. Finally, by removing the
-need to know the data types of the leafs, allows you to focus on the program
-logic.
-
-This top module imports the following modules:
-
-* alarm -- NSO alarm handling
-* application -- module for implementing packages and services
-* cdb -- placeholder for low-level _ncs.cdb items
-* dp -- data provider, actions
-* error -- placeholder for low-level _ncs.error items
-* events -- placeholder for low-level _ncs.events items
-* ha -- placeholder for low-level _ncs.ha items
-* log -- logging utilities
-* maagic -- data access module
-* maapi -- MAAPI interface
-* template -- module for working with templates
-* service_log -- module for doing service logging
-* upgrade -- module for writing upgrade components
-* util -- misc utilities
-
-## Submodules
-
-- [ncs.alarm](ncs.alarm.md): NCS Alarm Manager module.
-- [ncs.application](ncs.application.md): Module for building NCS applications.
-- [ncs.cdb](ncs.cdb.md): CDB high level module.
-- [ncs.dp](ncs.dp.md): Callback module for connecting data providers to ConfD/NCS.
-- [ncs.experimental](ncs.experimental.md): Experimental stuff.
-- [ncs.log](ncs.log.md): This module provides some logging utilities.
-- [ncs.maagic](ncs.maagic.md): Confd/NCS data access module.
-- [ncs.maapi](ncs.maapi.md): MAAPI high level module.
-- [ncs.progress](ncs.progress.md): MAAPI progress trace high level module.
-- [ncs.service_log](ncs.service_log.md): This module provides service logging
-- [ncs.template](ncs.template.md): This module implements classes to simplify template processing.
-- [ncs.util](ncs.util.md): Utility module, low level abstrations
-
-## Predefined Values
-
-```python
-
-ACCUMULATE = 1
-ADDR = '127.0.0.1'
-ALREADY_LOCKED = -4
-ATTR_ANNOTATION = 2147483649
-ATTR_BACKPOINTER = 2147483651
-ATTR_INACTIVE = 0
-ATTR_ORIGIN = 2147483655
-ATTR_ORIGINAL_VALUE = 2147483653
-ATTR_OUT_OF_BAND = 2147483664
-ATTR_REFCOUNT = 2147483650
-ATTR_TAGS = 2147483648
-ATTR_WHEN = 2147483652
-CANDIDATE = 1
-CMP_EQ = 1
-CMP_GT = 3
-CMP_GTE = 4
-CMP_LT = 5
-CMP_LTE = 6
-CMP_NEQ = 2
-CMP_NOP = 0
-CONFD_EOF = -2
-CONFD_ERR = -1
-CONFD_OK = 0
-CONFD_PORT = 4565
-CS_NODE_CMP_NORMAL = 0
-CS_NODE_CMP_SNMP = 1
-CS_NODE_CMP_SNMP_IMPLIED = 2
-CS_NODE_CMP_UNSORTED = 4
-CS_NODE_CMP_USER = 3
-CS_NODE_HAS_DISPLAY_WHEN = 1024
-CS_NODE_HAS_META_DATA = 2048
-CS_NODE_HAS_MOUNT_POINT = 32768
-CS_NODE_HAS_WHEN = 512
-CS_NODE_IS_ACTION = 8
-CS_NODE_IS_CASE = 128
-CS_NODE_IS_CDB = 4
-CS_NODE_IS_CONTAINER = 256
-CS_NODE_IS_DYN = 1
-CS_NODE_IS_LEAFREF = 16384
-CS_NODE_IS_LEAF_LIST = 8192
-CS_NODE_IS_LIST = 1
-CS_NODE_IS_NOTIF = 64
-CS_NODE_IS_PARAM = 16
-CS_NODE_IS_RESULT = 32
-CS_NODE_IS_STRING_AS_BINARY = 65536
-CS_NODE_IS_WRITE = 2
-CS_NODE_IS_WRITE_ALL = 4096
-C_BINARY = 39
-C_BIT32 = 29
-C_BIT64 = 30
-C_BITBIG = 50
-C_BOOL = 17
-C_BUF = 5
-C_CDBBEGIN = 37
-C_DATE = 20
-C_DATETIME = 19
-C_DECIMAL64 = 43
-C_DEFAULT = 42
-C_DOUBLE = 14
-C_DQUAD = 46
-C_DURATION = 27
-C_EMPTY = 53
-C_ENUM_HASH = 28
-C_ENUM_VALUE = 28
-C_HEXSTR = 47
-C_IDENTITYREF = 44
-C_INT16 = 7
-C_INT32 = 8
-C_INT64 = 9
-C_INT8 = 6
-C_IPV4 = 15
-C_IPV4PREFIX = 40
-C_IPV4_AND_PLEN = 48
-C_IPV6 = 16
-C_IPV6PREFIX = 41
-C_IPV6_AND_PLEN = 49
-C_LIST = 31
-C_NOEXISTS = 1
-C_OBJECTREF = 34
-C_OID = 38
-C_PTR = 36
-C_QNAME = 18
-C_STR = 4
-C_SYMBOL = 3
-C_TIME = 23
-C_UINT16 = 11
-C_UINT32 = 12
-C_UINT64 = 13
-C_UINT8 = 10
-C_UNION = 35
-C_XMLBEGIN = 32
-C_XMLBEGINDEL = 45
-C_XMLEND = 33
-C_XMLMOVEAFTER = 52
-C_XMLMOVEFIRST = 51
-C_XMLTAG = 2
-DB_INVALID = 0
-DB_VALID = 1
-DEBUG = 1
-DELAYED_RESPONSE = 2
-EOF = -2
-ERR = -1
-ERRCODE_ACCESS_DENIED = 3
-ERRCODE_APPLICATION = 4
-ERRCODE_APPLICATION_INTERNAL = 5
-ERRCODE_DATA_MISSING = 8
-ERRCODE_INCONSISTENT_VALUE = 2
-ERRCODE_INTERNAL = 7
-ERRCODE_INTERRUPT = 9
-ERRCODE_IN_USE = 0
-ERRCODE_PROTO_USAGE = 6
-ERRCODE_RESOURCE_DENIED = 1
-ERRINFO_KEYPATH = 0
-ERRINFO_STRING = 1
-ERR_ABORTED = 49
-ERR_ACCESS_DENIED = 3
-ERR_ALREADY_EXISTS = 2
-ERR_APPLICATION_INTERNAL = 39
-ERR_BADPATH = 8
-ERR_BADSTATE = 17
-ERR_BADTYPE = 5
-ERR_BAD_CONFIG = 36
-ERR_BAD_KEYREF = 14
-ERR_CLI_CMD = 59
-ERR_DATA_MISSING = 58
-ERR_EOF = 45
-ERR_EXTERNAL = 19
-ERR_HA_ABORT = 71
-ERR_HA_BADCONFIG = 69
-ERR_HA_BADFXS = 27
-ERR_HA_BADNAME = 29
-ERR_HA_BADTOKEN = 28
-ERR_HA_BADVSN = 52
-ERR_HA_BIND = 30
-ERR_HA_CLOSED = 26
-ERR_HA_CONNECT = 25
-ERR_HA_NOTICK = 31
-ERR_HA_WITH_UPGRADE = 47
-ERR_INCONSISTENT_VALUE = 38
-ERR_INTERNAL = 18
-ERR_INUSE = 11
-ERR_INVALID_INSTANCE = 43
-ERR_LIB_NOT_INITIALIZED = 34
-ERR_LOCKED = 10
-ERR_MALLOC = 20
-ERR_MISSING_INSTANCE = 42
-ERR_MUST_FAILED = 41
-ERR_NOEXISTS = 1
-ERR_NON_UNIQUE = 13
-ERR_NOSESSION = 22
-ERR_NOSTACK = 9
-ERR_NOTCREATABLE = 6
-ERR_NOTDELETABLE = 7
-ERR_NOTMOVABLE = 46
-ERR_NOTRANS = 61
-ERR_NOTSET = 12
-ERR_NOT_IMPLEMENTED = 51
-ERR_NOT_WRITABLE = 4
-ERR_NO_MOUNT_ID = 67
-ERR_OS = 24
-ERR_POLICY_COMPILATION_FAILED = 54
-ERR_POLICY_EVALUATION_FAILED = 55
-ERR_POLICY_FAILED = 53
-ERR_PROTOUSAGE = 21
-ERR_RESOURCE_DENIED = 37
-ERR_STALE_INSTANCE = 68
-ERR_START_FAILED = 57
-ERR_SUBAGENT_DOWN = 33
-ERR_TIMEOUT = 48
-ERR_TOOMANYTRANS = 23
-ERR_TOO_FEW_ELEMS = 15
-ERR_TOO_MANY_ELEMS = 16
-ERR_TOO_MANY_SESSIONS = 35
-ERR_TRANSACTION_CONFLICT = 70
-ERR_UNAVAILABLE = 44
-ERR_UNSET_CHOICE = 40
-ERR_UPGRADE_IN_PROGRESS = 60
-ERR_VALIDATION_WARNING = 32
-ERR_XPATH = 50
-EXEC_COMPARE = 13
-EXEC_CONTAINS = 11
-EXEC_DERIVED_FROM = 9
-EXEC_DERIVED_FROM_OR_SELF = 10
-EXEC_RE_MATCH = 8
-EXEC_STARTS_WITH = 7
-EXEC_STRING_COMPARE = 12
-FALSE = 0
-FIND_NEXT = 0
-FIND_SAME_OR_NEXT = 1
-HKP_MATCH_FULL = 3
-HKP_MATCH_HKP = 2
-HKP_MATCH_NONE = 0
-HKP_MATCH_TAGS = 1
-INTENDED = 7
-IN_USE = -5
-ITER_CONTINUE = 3
-ITER_RECURSE = 2
-ITER_STOP = 1
-ITER_SUSPEND = 4
-ITER_UP = 5
-ITER_WANT_ANCESTOR_DELETE = 2
-ITER_WANT_ATTR = 4
-ITER_WANT_CLI_ORDER = 1024
-ITER_WANT_CLI_STR = 8
-ITER_WANT_LEAF_FIRST_ORDER = 32
-ITER_WANT_LEAF_LAST_ORDER = 64
-ITER_WANT_PREV = 1
-ITER_WANT_P_CONTAINER = 256
-ITER_WANT_REVERSE = 128
-ITER_WANT_SCHEMA_ORDER = 16
-ITER_WANT_SUPPRESS_OPER_DEFAULTS = 2048
-LF_AND = 1
-LF_CMP = 3
-LF_CMP_LL = 7
-LF_EXEC = 5
-LF_EXISTS = 4
-LF_NOT = 2
-LF_OR = 0
-LF_ORIGIN = 6
-LIB_API_VSN = 134610944
-LIB_API_VSN_STR = '08060000'
-LIB_PROTO_VSN = 86
-LIB_PROTO_VSN_STR = '86'
-LIB_VSN = 134610944
-LIB_VSN_STR = '08060000'
-LISTENER_CLI = 8
-LISTENER_IPC = 1
-LISTENER_NETCONF = 2
-LISTENER_SNMP = 4
-LISTENER_WEBUI = 16
-LOAD_SCHEMA_HASH = 65536
-LOAD_SCHEMA_NODES = 1
-LOAD_SCHEMA_TYPES = 2
-MMAP_SCHEMAS_FIXED_ADDR = 2
-MMAP_SCHEMAS_KEEP_SIZE = 1
-MOP_ATTR_SET = 6
-MOP_CREATED = 1
-MOP_DELETED = 2
-MOP_MODIFIED = 3
-MOP_MOVED_AFTER = 5
-MOP_VALUE_SET = 4
-NCS_ERR_CONNECTION_CLOSED = 64
-NCS_ERR_CONNECTION_REFUSED = 56
-NCS_ERR_CONNECTION_TIMEOUT = 63
-NCS_ERR_DEVICE = 65
-NCS_ERR_SERVICE_CONFLICT = 62
-NCS_ERR_TEMPLATE = 66
-NCS_LISTENER_NETCONF_CALL_HOME = 32
-NCS_PORT = 4569
-NO_DB = 0
-OK = 0
-OPERATIONAL = 4
-PATH = None
-PORT = 4569
-PRE_COMMIT_RUNNING = 6
-PROGRESS_INFO = 3
-PROGRESS_START = 1
-PROGRESS_STOP = 2
-PROTO_CONSOLE = 4
-PROTO_HTTP = 6
-PROTO_HTTPS = 7
-PROTO_SSH = 2
-PROTO_SSL = 5
-PROTO_SYSTEM = 3
-PROTO_TCP = 1
-PROTO_TLS = 9
-PROTO_TRACE = 3
-PROTO_UDP = 8
-PROTO_UNKNOWN = 0
-QUERY_HKEYPATH = 1
-QUERY_HKEYPATH_VALUE = 2
-QUERY_STRING = 0
-QUERY_TAG_VALUE = 3
-READ = 1
-READ_WRITE = 2
-RUNNING = 2
-SERIAL_HKEYPATH = 2
-SERIAL_NONE = 0
-SERIAL_TAG_VALUE = 3
-SERIAL_VALUE_T = 1
-SILENT = 0
-SNMP_COL_ROW = 3
-SNMP_Counter32 = 6
-SNMP_Counter64 = 9
-SNMP_INTEGER = 1
-SNMP_Interger32 = 2
-SNMP_IpAddress = 5
-SNMP_NULL = 0
-SNMP_OBJECT_IDENTIFIER = 4
-SNMP_OCTET_STRING = 3
-SNMP_OID = 2
-SNMP_Opaque = 8
-SNMP_TimeTicks = 7
-SNMP_Unsigned32 = 10
-SNMP_VARIABLE = 1
-STARTUP = 3
-TIMEZONE_UNDEF = -111
-TRACE = 2
-TRANSACTION = 5
-TRANS_CB_FLAG_FILTERED = 1
-TRUE = 1
-USESS_FLAG_FORWARD = 1
-USESS_FLAG_HAS_IDENTIFICATION = 2
-USESS_FLAG_HAS_OPAQUE = 4
-USESS_LOCK_MODE_EXCLUSIVE = 2
-USESS_LOCK_MODE_NONE = 0
-USESS_LOCK_MODE_PRIVATE = 1
-USESS_LOCK_MODE_SHARED = 3
-VALIDATION_FLAG_COMMIT = 2
-VALIDATION_FLAG_TEST = 1
-VALIDATION_WARN = -3
-VERBOSITY_DEBUG = 3
-VERBOSITY_NORMAL = 0
-VERBOSITY_VERBOSE = 1
-VERBOSITY_VERY_VERBOSE = 2
-```
diff --git a/developer-reference/pyapi/ncs.progress.md b/developer-reference/pyapi/ncs.progress.md
deleted file mode 100644
index 7303bec4..00000000
--- a/developer-reference/pyapi/ncs.progress.md
+++ /dev/null
@@ -1,134 +0,0 @@
-# Python ncs.progress Module
-
-MAAPI progress trace high level module.
-
-This module defines a high level interface to the low-level maapi functions.
-
-In the Progress Trace a span is used to meassure duration of an event, the
-'start' and 'stop' messages in the progress trace log:
-
-start,2023-08-28T10:42:51.249865,,,,45,306,running,cli,,"foobar"...
-...
-stop,2023-08-28T10:42:51.284359,0.034494,,,45,306,running,cli,,"foobar"...
-
-maapi.Transaction.start_progress_span() and
-maapi.Maapi.start_progress_span() return progress.Span objects, which
-contains the span_id and trace_id (if enabled) attributes. Once the object
-is deleted/exited or manually obj.end() is called the stop message is
-written to the progress trace.
-
-Inside a span multiple sub spans can be created, sp2 in the below example.
-
- import ncs
-
- m = ncs.maapi.Maapi()
- m.start_user_session('admin', my context')
- t = m.start_read_trans()
- sp1 = t.start_progress_span('first span')
- t.progress_info('info message')
- sp2 = t.start_progress_span('second span')
- sp2.end()
- sp1.end()
-
-Another way is to use context managers, which will handle all cleanup
-related to transactions, user sessions and socket connections:
-
- with ncs.maapi.Maapi() as m:
- m.start_user_session('admin', my context')
- with m.start_read_trans() as t:
- with t.start_progress_span('first span'):
- t.progress_info('info message')
- with t.start_progress_span('second span'):
- pass
-
-Finally, a really compact way of doing this:
-
- with ncs.maapi.single_read_trans('admin', 'my context') as t:
- with t.start_progress_span('first span'):
- t.progress_info('info message')
- with t.start_progress_span( 'second span')
- pass
-
-There are multiple optional fields.
-
- with ncs.maapi.single_read_trans('admin', 'my context') as t:
- with t.start_progress_span('calling foo',
- attrs={'sys':'Linux', 'hostname':'bob'}):
- foo()
-
- with ncs.maapi.Maapi() as m:
- m.start_user_session('admin', 'my context')
- action = '/devices/device{ex0}/sync-from'
- with m.start_progress_span('copy running from ex0', path=action):
- m.request_action([], 0, action)
-
- # trace_id1 from an already existing trace
- trace_id1 = 'b1ce20b4-0ca4-4a3e-a448-8df860e622e0'
- with ncs.maapi.single_read_trans('admin', 'my context') as t:
- with t.start_progress_span('perform op related to old trace',
- links=[{'trace_id':trace_id1]}):
- pass
-
-## Functions
-
-### conv_links
-
-```python
-conv_links(links)
-```
-
-convert from [Span() | dict()] -> [dict()]
-
-
-## Classes
-
-### _class_ **EmptySpan**
-
-
-```python
-EmptySpan(span_id=None, trace_id=None)
-```
-
-Members:
-
-validate(...)
- -Method: - -```python -validate(self, unlock, forcevalidation=False) -``` - -Validate the transaction. - -This function validates all data written in the transaction. This -includes all data model constraints and all defined semantic -validation, i.e. user programs that have registered functions under -validation points. - -If 'unlock' is True, the transaction is open for further editing even -if validation succeeds. If 'unlock' is False and the function succeeds -next function to be called MUST be prepare() or finish(). - -'unlock = True' can be used to implement a 'validate' command which -can be given in the middle of an editing session. The first thing that -happens is that a lock is set. If 'unlock' == False, the lock is -released on success. The lock is always released on failure. - -The 'forcevalidation' argument should normally be False. It has no -effect for a transaction towards the running or startup data stores, -validation is always performed. For a transaction towards the -candidate data store, validation will not be done unless -'forcevalidation' is True. Avoiding this validation is preferable if -we are going to commit the candidate to running, since otherwise the -validation will be done twice. However if we are implementing a -'validate' command, we should give a True value for 'forcevalidation'. - -Arguments: - -* unlock (boolean) -* forcevalidation (boolean) - -
-
-
-
-### _class_ **Span**
-
-
-```python
-Span(msock, span_id, trace_id=None)
-```
-
-Members:
-
-end(...)
- -Method: - -```python -end(self, *args) -``` - -not implemented. no span to end. - -
-
-
-
diff --git a/developer-reference/pyapi/ncs.service_log.md b/developer-reference/pyapi/ncs.service_log.md
deleted file mode 100644
index 1b23a610..00000000
--- a/developer-reference/pyapi/ncs.service_log.md
+++ /dev/null
@@ -1,88 +0,0 @@
-# Python ncs.service_log Module
-
-This module provides service logging
-
-## Classes
-
-### _class_ **ServiceLog**
-
-This class contains methods to write service log entries.
-
-```python
-ServiceLog(node_or_maapi)
-```
-
-Initialize a service log object.
-
-Members:
-
-end(...)
- -Method: - -```python -end(self, annotation=None) -``` - -ends a span, the stop event in the progress trace. this function -is called automatically when the span is deleted i.e. when exiting a -'with' context. - -* annotation -- sets the annotation field for stop events (str) - -
-
-
-
-debug(...)
- -Method: - -```python -debug(self, path, msg, type) -``` - -Log a debug message. - -
-
-
-
-error(...)
- -Method: - -```python -error(self, path, msg, type) -``` - -Log an error message. - -
-
-
-
-info(...)
- -Method: - -```python -info(self, path, msg, type) -``` - -Log an information message. - -
-
-
-
-trace(...)
- -Method: - -```python -trace(self, path, msg, type) -``` - -Log a trace message. - -
-
-
-
diff --git a/developer-reference/pyapi/ncs.template.md b/developer-reference/pyapi/ncs.template.md
deleted file mode 100644
index eaaa2b10..00000000
--- a/developer-reference/pyapi/ncs.template.md
+++ /dev/null
@@ -1,284 +0,0 @@
-# Python ncs.template Module
-
-This module implements classes to simplify template processing.
-
-## Classes
-
-### _class_ **Template**
-
-Class to simplify applying of templates in a NCS service callback.
-
-```python
-Template(service, path=None)
-```
-
-Initialize a Template object.
-
-The 'service' argument is the 'service' variable received in
-decorated cb_create method in a service class.
-('service' can in fact be any maagic.Node (except a Root node)
-instance with an underlying Transaction). It is also possible to
-provide a maapi.Transaction instance for the 'service' argument in
-which case 'path' must also be provided.
-
-Example use:
-
- vars = ncs.template.Variables()
- vars.add('VAR1', 'foo')
- vars.add('VAR2', 'bar')
- vars.add('VAR3', 42)
- template = ncs.template.Template(service)
- template.apply('my-service-template', vars)
-
-Members:
-
-warn(...)
- -Method: - -```python -warn(self, path, msg, type) -``` - -Log an warning message. - -
-
-
-
-### _class_ **Variables**
-
-Class to simplify passing of variables when applying a template.
-
-```python
-Variables(init=None)
-```
-
-Initialize a Variables object.
-
-The optional argument 'init' can be any iterable yielding a
-2-tuple in the form (name, value).
-
-Members:
-
-apply(...)
- -Method: - -```python -apply(self, name, vars=None, flags=0) -``` - -Apply the template 'name'. - -The optional argument 'vars' may be provided in form of a -Variables instance. - -Arguments: - -* name -- template name (str) -* vars -- template variables (template.Variables) -* flags -- template flags (int, optional) - -
-
-
-
-add(...)
- -Method: - -```python -add(self, name, value) -``` - -Add a value for the variable 'name'. - -The value will be quoted before adding it to the internal list. - -Quoting works like this: - If value contains ' all occurrences of " will be replaced by ' and - the final value will be quoted with ". Otherwise, the final value - will be quoted with '. - -Arguments: - -* name -- service variable name (str) -* value -- variable value (str, int, boolean) - -
-
-
-
-add_plain(...)
- -Method: - -```python -add_plain(self, name, value) -``` - -Add a value for the variable 'name'. - -It's up to the caller to do proper quoting of value. - -For arguments, see Variables.add() - -
-
-
-
-append(...)
- -Method: - -```python -append(self, object, /) -``` - -Append object to the end of the list. - -
-
-
-
-clear(...)
- -Method: - -```python -clear(self, /) -``` - -Remove all items from list. - -
-
-
-
-copy(...)
- -Method: - -```python -copy(self, /) -``` - -Return a shallow copy of the list. - -
-
-
-
-count(...)
- -Method: - -```python -count(self, value, /) -``` - -Return number of occurrences of value. - -
-
-
-
-extend(...)
- -Method: - -```python -extend(self, iterable, /) -``` - -Extend list by appending elements from the iterable. - -
-
-
-
-index(...)
- -Method: - -```python -index(self, value, start=0, stop=9223372036854775807, /) -``` - -Return first index of value. - -Raises ValueError if the value is not present. - -
-
-
-
-insert(...)
- -Method: - -```python -insert(self, index, object, /) -``` - -Insert object before index. - -
-
-
-
-pop(...)
- -Method: - -```python -pop(self, index=-1, /) -``` - -Remove and return item at index (default last). - -Raises IndexError if list is empty or index is out of range. - -
-
-
-
-remove(...)
- -Method: - -```python -remove(self, value, /) -``` - -Remove first occurrence of value. - -Raises ValueError if the value is not present. - -
-
-
-
-reverse(...)
- -Method: - -```python -reverse(self, /) -``` - -Reverse *IN PLACE*. - -
-
-
-
diff --git a/developer-reference/pyapi/ncs.util.md b/developer-reference/pyapi/ncs.util.md
deleted file mode 100644
index 706204b3..00000000
--- a/developer-reference/pyapi/ncs.util.md
+++ /dev/null
@@ -1,89 +0,0 @@
-# Python ncs.util Module
-
-Utility module, low level abstrations
-
-## Functions
-
-### get_callpoint_model
-
-```python
-get_callpoint_model()
-```
-
-Get configured callpoint model
-
-### get_self_assign_warning
-
-```python
-get_self_assign_warning()
-```
-
-Return current self assign warning type.
-
-### get_setattr_fun
-
-```python
-get_setattr_fun(obj, parent)
-```
-
-Return setattr fun to use for setting attributes, will use
-return a wrapped setattr function with sanity checks if enabled.
-
-### is_multiprocessing
-
-```python
-is_multiprocessing()
-```
-
-Return True if the configured callpoint model is multiprocessing
-
-### mk_yang_date_and_time
-
-```python
-mk_yang_date_and_time(dt=None)
-```
-
-Create a timezone aware datetime object in ISO8601 string format.
-
-This method is used to convert a datetime object to its timezone aware
-counterpart and return a string useful for a 'yang:date-and-time' leaf.
-If 'dt' is None the current time will be used.
-
-Arguments:
- dt -- a datetime object to be converted (optional)
-
-### set_callpoint_model
-
-```python
-set_callpoint_model(model)
-```
-
-Update environment with provided callpoint model
-
-### set_kill_child_on_parent_exit
-
-```python
-set_kill_child_on_parent_exit()
-```
-
-Multi OS variant of _ncs.set_kill_child_on_parent_exit falling back
-to kqueue if the OS supports it.
-
-### set_self_assign_warning
-
-```python
-set_self_assign_warning(warning)
-```
-
-Set self assign warning type.
-
-### with_setattr_check
-
-```python
-with_setattr_check(path)
-```
-
-Use as context manager enabling set attribute check for the
-current thread while in the manager.
-
-
diff --git a/developer-reference/restconf-api/README.md b/developer-reference/restconf-api/README.md
deleted file mode 100644
index 0e1c49f6..00000000
--- a/developer-reference/restconf-api/README.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-description: Implementation details for RESTCONF.
-icon: code
----
-
-# RESTCONF API
-
-The NSO RESTCONF documentation covers implementation details and extension to or deviation from the RESTCONF RFC 8040 and YANG RFC 7950 respectively. The IETF RESTCONF and YANG RFCs are the main reference guides for the NSO RESTCONF interface, while the NSO documentation complements the RFCs.
-
-{% embed url="https://datatracker.ietf.org/doc/html/rfc8040" %}
-
-{% embed url="https://datatracker.ietf.org/doc/html/rfc7950" %}
-
-{% embed url="https://datatracker.ietf.org/doc/html/rfc7951" %}
-
-{% embed url="https://cisco-tailf.gitbook.io/nso-docs/guides/development/core-concepts/northbound-apis/restconf-api" %}
diff --git a/developer-reference/snmp-agent.md b/developer-reference/snmp-agent.md
deleted file mode 100644
index 76c1712f..00000000
--- a/developer-reference/snmp-agent.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-description: Description of SNMP agent.
-icon: message-bot
----
-
-# SNMP Agent
-
-Visit the link below to learn more.
-
-{% embed url="https://cisco-tailf.gitbook.io/nso-docs/guides/development/core-concepts/northbound-apis/nso-snmp-agent" %}
diff --git a/developer-reference/xpath.md b/developer-reference/xpath.md
deleted file mode 100644
index b05632e4..00000000
--- a/developer-reference/xpath.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-description: Implementation details for XPath.
-icon: value-absolute
----
-
-# XPath
-
-The NSO XPath documentation covers implementation details and extension to or deviation from the XPath 1.0 documentation and YANG RFC 7950 XPath extensions respectively. The XPath 1.0 documentation and YANG RFCs are the main reference guides for the NSO XPath implementation, while the NSO documentation complements them.
-
-{% embed url="https://www.w3.org/TR/1999/REC-xpath-19991116/" %}
-
-{% embed url="https://datatracker.ietf.org/doc/html/rfc7950#section-10" %}
-
-{% embed url="https://nso-docs.cisco.com/guides/resources/index#section-5-file-formats-and-syntax" %}
diff --git a/development/advanced-development/README.md b/development/advanced-development/README.md
deleted file mode 100644
index 33071de0..00000000
--- a/development/advanced-development/README.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-description: Advanced-level NSO development.
-icon: stairs
----
-
-# Advanced Development
-
diff --git a/development/advanced-development/developing-alarm-applications.md b/development/advanced-development/developing-alarm-applications.md
deleted file mode 100644
index 3d49755e..00000000
--- a/development/advanced-development/developing-alarm-applications.md
+++ /dev/null
@@ -1,383 +0,0 @@
----
-description: Manipulate NSO alarm table using the dedicated Alarm APIs.
----
-
-# Developing Alarm Applications
-
-This section focuses on how to manipulate the NSO alarm table using the dedicated Alarm APIs. Make sure that the concepts in the [Alarm Manager](../../operation-and-usage/operations/alarm-manager.md) introduction are well understood before reading this section.
-
-The Alarm API provides a simplified way of managing your alarms for the most common alarm management use cases. The API is divided into a producer and a consumer part.
-
-The producer part provides an alarm sink. Using an alarm sink, you can submit your alarms into the system. The alarms are then queued and fed into the NSO alarm list. You can have multiple alarm sinks active at any time.
-
-The consumer part provides an Alarm Source. The alarm source lets you listen to new alarms and alarm changes. As with the producer side, you can have multiple alarm sources listening for new and changed alarms in parallel.
-
-The diagram below shows a high-level view of the flow of alarms in and out of the system. Alarms are received, e.g. as SNMP notifications, and fed into the NSO Alarm List. At the other end, you subscribe for the alarm changes.
-
-sort(...)
- -Method: - -```python -sort(self, /, *, key=None, reverse=False) -``` - -Sort the list in ascending order and return None. - -The sort is in-place (i.e. the list itself is modified) and stable (i.e. the -order of two equal elements is maintained). - -If a key function is given, apply it once to each list item and sort them, -ascending or descending, according to their function values. - -The reverse flag can be set to sort in descending order. - -
The Alarm Flow
Alarm into the alarm list.
- * If the alarms key
- * "managedDevice, managedObject, alarmType, specificProblem" already
- * exists, the existing alarm will be updated with a
- * new status change entry.
- *
- * Alarm identity:
- *
- * @param managedDevice the managed device which emits the alarm.
- *
- * @param managedObject the managed object emitting the alarm.
- *
- * @param alarmtype the alarm type of the alarm.
- *
- * @param specificProblem is used when the alarmtype cannot uniquely
- * identify the alarm type. Normally, this is not the case,
- * and this leaf is the empty string.
- *
- * Status change within the alarm:
- * @param severity the severity of the alarm.
- * @param alarmText the alarm text
- * @param impactedObjects Objects that might be affected by this alarm
- * @param relatedAlarms Alarms related to this alarm
- * @param rootCauseObjects Objects that are candidates for causing the
- * alarm.
- * @param timeStamp The time the status of the alarm changed,
- * as reported by the device
- * @param customAttributes Custom attributes
- *
- * @return boolean true/false whether the submitting the specified
- * alarm was successful
- *
- * @throws IOException
- * @throws ConfException
- * @throws NavuException
- */
- public synchronized boolean
- submitAlarm(ManagedDevice managedDevice,
- ManagedObject managedObject,
- ConfIdentityRef alarmtype,
- ConfBuf specificProblem,
- PerceivedSeverity severity,
- ConfBuf alarmText,
- List| Non transactional devices | Transactional devices | Transactional devices with confirmed commit | Fully capable NETCONF server |
|---|---|---|---|
| SNMP, Cisco IOS, NETCONF devices with startup+running. | Devices that can abort, NETCONF devices without confirmed commit. | Cisco XR type of devices. | ConfD, Junos. |
| Non transactional devices | Transactional devices | Transactional devices with confirmed commit | Fully capable NETCONF server |
|---|---|---|---|
initialize(). NED code shall make the device go into config mode (if applicable) and lock (if applicable). | initialize(). NED code shall start a transaction on the device. | initialize(). NED code shall do the equivalent of configure exclusive. | Built in, NSO will lock. |
| Non transactional devices | Transactional devices | Transactional devices with confirmed commit | Fully capable NETCONF server |
|---|---|---|---|
uninitialize(). NED code shall unlock (if applicable). | uninitialize(). NED code shall abort the transaction. | uninitialize(). NED code shall abort the transaction. | Built in, NSO will unlock. |
| Non transactional devices | Transactional devices | Transactional devices with confirmed commit | Fully capable NETCONF server |
|---|---|---|---|
prepare(Data). NED code shall send all data to the device. | prepare(Data). NED code shall add Data to the transaction and validate. | prepare(Data). NED code shall add Data to the transaction and validate. | Built in, NSO will edit-config towards the candidate, validate and commit confirmed with a timeout. |
| Non transactional devices | Transactional devices | Transactional devices with confirmed commit | Fully capable NETCONF server |
|---|---|---|---|
abort(ReverseData | null) Either do the equivalent of copy startup to running, or apply the ReverseData to the device. | abort(ReverseData | null). Abort the transaction | abort(ReverseData | null). Abort the transaction | Built in, discard-changes and close. |
| Non transactional devices | Transactional devices | Transactional devices with confirmed commit | Fully capable NETCONF server |
|---|---|---|---|
commit(Timeout). Do nothing | commit(Timeout). Commit the transaction. | commit(Timeout). Execute commit confirmed [Timeout] on the device. | Built in, commit confirmed with the timeout. |
| Non transactional devices | Transactional devices | Transactional devices with confirmed commit | Fully capable NETCONF server |
|---|---|---|---|
revert(ReverseData | null) Either do the equivalent of copy startup to running, or apply the ReverseData to the device. | revert(ReverseData | null) Either do the equivalent of copy startup to running, or apply the ReverseData to the device. | revert(ReverseData | null). discard-changes | Built in, discard-changes and close. |
| Non transactional devices | Transactional devices | Transactional devices with confirmed commit | Fully capable NETCONF server |
|---|---|---|---|
persist() Either do the equivalent of copy running to startup or nothing. | persist() Either do the equivalent of copy running to startup or nothing. | persist(). confirm. | Built in, commit confirm. |
NED Transaction States
NED Dry-run States
-
-
-
-Used for adding a submode in a container. The default rendering engine maps a container as a command prefix and a list node as a submode. However, sometimes entering a submode does not require the user to give a specific instance. In these cases, you can use the `tailf:cli-add-mode` on a container:
-
-```yang
-container system {
- tailf:info "For system events.";
- container "default" {
- tailf:cli-add-mode;
- tailf:cli-mode-name "cfg-acct-mlist";
- tailf:cli-delete-when-empty;
- presence true;
- container start-stop {
- tailf:info "Record start and stop without waiting";
- leaf group {
- tailf:info "Use Server-group";
- type aaa-group-type;
- }
- }
- }
-}
-```
-
-In this example, the `tailf:cli-add-mode` annotations tell the CLI engine to render the `default` container as a submode, in other words, there will be a command `system default` for entering the default container as a submode. All further commands will use that context as a base. In the example above, the `default` container will only contain one command `start-stop group`, rendered from the `start-stop` container (rendered as a prefix) and the `group` leaf.
-
-
-
-tailf:cli-add-mode
-
-Used for adding a submode in a container. The default rendering engine maps a container as a command prefix and a list node as a submode. However, sometimes entering a submode does not require the user to give a specific instance. In these cases, you can use the `tailf:cli-add-mode` on a container:
-
-```yang
-container system {
- tailf:info "For system events.";
- container "default" {
- tailf:cli-add-mode;
- tailf:cli-mode-name "cfg-acct-mlist";
- tailf:cli-delete-when-empty;
- presence true;
- container start-stop {
- tailf:info "Record start and stop without waiting";
- leaf group {
- tailf:info "Use Server-group";
- type aaa-group-type;
- }
- }
- }
-}
-```
-
-In this example, the `tailf:cli-add-mode` annotations tell the CLI engine to render the `default` container as a submode, in other words, there will be a command `system default` for entering the default container as a submode. All further commands will use that context as a base. In the example above, the `default` container will only contain one command `start-stop group`, rendered from the `start-stop` container (rendered as a prefix) and the `group` leaf.
-
-
-
-
-
-Tells the parser that the list name is allowed to be joined together with the first key, i.e. written without space in between. This is used to render, for example, the `interface FastEthernet` command where the list is `FastEthernet` and the key is the interface name. In a typical Cisco CLI they are allowed to be written both as **i**`nterface FastEthernet 1` and as `interface FastEthernet1`.
-
-```yang
-list FastEthernet {
- tailf:info "FastEthernet IEEE 802.3";
- tailf:cli-allow-join-with-key {
- tailf:cli-display-joined;
- }
- tailf:cli-mode-name "config-if";
- key name;
- leaf name {
- type string {
- pattern "[0-9]+.*";
- tailf:info "<0-66>/<0-128>;;FastEthernet interface number";
- }
-}
-```
-
-In the above example, the `tailf:cli-display-joined` substatement is used to tell the command renderer that it should display a list item using the format without space.
-
-
-
-tailf:cli-allow-join-with-key
-
-Tells the parser that the list name is allowed to be joined together with the first key, i.e. written without space in between. This is used to render, for example, the `interface FastEthernet` command where the list is `FastEthernet` and the key is the interface name. In a typical Cisco CLI they are allowed to be written both as **i**`nterface FastEthernet 1` and as `interface FastEthernet1`.
-
-```yang
-list FastEthernet {
- tailf:info "FastEthernet IEEE 802.3";
- tailf:cli-allow-join-with-key {
- tailf:cli-display-joined;
- }
- tailf:cli-mode-name "config-if";
- key name;
- leaf name {
- type string {
- pattern "[0-9]+.*";
- tailf:info "<0-66>/<0-128>;;FastEthernet interface number";
- }
-}
-```
-
-In the above example, the `tailf:cli-display-joined` substatement is used to tell the command renderer that it should display a list item using the format without space.
-
-
-
-
-
-This tells the parser that a leaf value is allowed to be written without space between the leaf name and the value. This is typically the case when referring to an interface. For example:
-
-```yang
-leaf FastEthernet {
- tailf:info "FastEthernet IEEE 802.3";
- tailf:cli-allow-join-with-value {
- tailf:cli-display-joined;
- }
- type string;
- tailf:non-strict-leafref {
- path "/ios:interface/ios:FastEthernet/ios:name";
- }
-}
-```
-
-In the example above, a leaf FastEthernet is used to point to an existing interface. The command is allowed to be written both as `FastEthernet 1` and as `FastEthernet1`, when referring to FastEthernet interface 1. The substatements say which is the preferred format when rendering the command.
-
-
-
-tailf:cli-allow-join-with-value
-
-This tells the parser that a leaf value is allowed to be written without space between the leaf name and the value. This is typically the case when referring to an interface. For example:
-
-```yang
-leaf FastEthernet {
- tailf:info "FastEthernet IEEE 802.3";
- tailf:cli-allow-join-with-value {
- tailf:cli-display-joined;
- }
- type string;
- tailf:non-strict-leafref {
- path "/ios:interface/ios:FastEthernet/ios:name";
- }
-}
-```
-
-In the example above, a leaf FastEthernet is used to point to an existing interface. The command is allowed to be written both as `FastEthernet 1` and as `FastEthernet1`, when referring to FastEthernet interface 1. The substatements say which is the preferred format when rendering the command.
-
-
-
-
-
-Normally, keys come before other leaves when a list command is used, and this is required in YANG. However, this is not always the case in Cisco-style CLIs. For example the `route-map` command where the name and sequence numbers are the keys, but the leaf operation (permit or deny) is given in between the first and the second key. The `tailf:cli-prefix-key` annotation tells the parser to expect a given leaf before the keys, but the substatement `tailf:cli-before-key ` can be used to specify that the leaf should occur in between two keys. For example:
-
-```yang
-list route-map {
- tailf:info "Route map tag";
- tailf:cli-mode-name "config-route-map";
- tailf:cli-compact-syntax;
- tailf:cli-full-command;
- key "name sequence";
- leaf name {
- type string {
- tailf:info "WORD;;Route map tag";
- }
- }
- // route-map * #
- leaf sequence {
- tailf:cli-drop-node-name;
- type uint16 {
- tailf:info "<0-65535>;;Sequence to insert to/delete from "
- +"existing route-map entry";
- range "0..65535";
- }
- }
- // route-map * permit
- // route-map * deny
- leaf operation {
- tailf:cli-drop-node-name;
- tailf:cli-prefix-key {
- tailf:cli-before-key 2;
- }
- type enumeration {
- enum deny {
- tailf:code-name "op_deny";
- tailf:info "Route map denies set operations";
- }
- enum permit {
- tailf:code-name "op_internet";
- tailf:info "Route map permits set operations";
- }
- }
- default permit;
- }
-}
-```
-
-A lot of things are going on in the example above, in addition to the `tailf:cli-prefix-key` and `tailf:cli-before-key` annotations. The `tailf:cli-drop-node-name` annotation tells the parser to ignore the name of the leaf (to not accept that as input, or render it when displaying the configuration).
-
-
-
-tailf:cli-prefix-key and tailf:cli-before-key
-
-Normally, keys come before other leaves when a list command is used, and this is required in YANG. However, this is not always the case in Cisco-style CLIs. For example the `route-map` command where the name and sequence numbers are the keys, but the leaf operation (permit or deny) is given in between the first and the second key. The `tailf:cli-prefix-key` annotation tells the parser to expect a given leaf before the keys, but the substatement `tailf:cli-before-key
-
-
-
-This tells the parser to render a leaf of type boolean as `no ` and `` instead of the default ` false` and ` true`. The other alternative to this is to use a leaf of type empty and the `tailf:cli-show-no` annotation. The difference is subtle. A leaf with `tailf:cli-boolean-no` would not be displayed unless explicitly configured to either true or false, whereas a type empty leaf with `tailf:cli-show-no` would always be displayed if not set. For example:
-
-```yang
-leaf keepalive {
- tailf:info "Enable keepalive";
- tailf:cli-boolean-no;
- type boolean;
-}
-```
-
-In the above example the `keepalive` leaf is set to true when the command `keepalive` is given, and to false when `no keepalive` is given. The well known `shutdown` command, on the other hand, is modeled as a type empty leaf with the `tailf:cli-show-no` annotation:
-
-```yang
-leaf shutdown {
- // Note: default to "no shutdown" in order to be able to bring if up.
- tailf:info "Shutdown the selected interface";
- tailf:cli-full-command;
- tailf:cli-show-no;
- type empty;
-}
-```
-
-
-
-tailf:cli-boolean-no
-
-This tells the parser to render a leaf of type boolean as `no
-
-
-
-These annotations are used to tell the CLI to only accept leaves in a container in the same order as they appears in the data model. This is typically required when the leaf names are hidden using the `tailf:cli-drop-node-name` annotation. It is very common in the Cisco CLI that commands accept multiple parameters, and such commands must be mapped to setting of multiple leaves in the data model. For example the `aggregate-address` command in the `router bgp` submode:
-
-```
-// router bgp * / aggregate-address
-container aggregate-address {
- tailf:info "Configure BGP aggregate entries";
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands {
- tailf:cli-reset-all-siblings;
- }
- leaf address {
- tailf:cli-drop-node-name;
- type inet:ipv4-address {
- tailf:info "A.B.C.D;;Aggregate address";
- }
- }
- leaf mask {
- tailf:cli-drop-node-name;
- type inet:ipv4-address {
- tailf:info "A.B.C.D;;Aggregate mask";
- }
- }
- leaf advertise-map {
- tailf:cli-break-sequence-commands;
- tailf:info "Set condition to advertise attribute";
- type string {
- tailf:info "WORD;;Route map to control attribute "
- +"advertisement";
- }
- }
- leaf as-set {
- tailf:info "Generate AS set path information";
- type empty;
- }
- leaf attribute-map {
- type string {
- tailf:info "WORD;;Route map for parameter control";
- }
- }
- leaf as-override {
- tailf:info "Override matching AS-number while sending update";
- type empty;
- }
- leaf route-map {
- type string {
- tailf:info "WORD;;Route map for parameter control";
- }
- }
- leaf summary-only {
- tailf:info "Filter more specific routes from updates";
- type empty;
- }
- leaf suppress-map {
- tailf:info "Conditionally filter more specific routes from "
- +"updates";
- type string {
- tailf:info "WORD;;Route map for suppression";
- }
- }
-}
-```
-
-In the above example, the `tailf:cli-sequence-commands` annotation tells the parser to require the leaves in the `aggregate-address` container to be entered in the same order as in the data model, i.e. first address then mask. Since these leaves also have the `tailf:cli-drop-node-name` annotation, it would be impossible for the parser to know which leaf to map the values to, unless the order of appearance was used. The `tailf:cli-break-sequence-commands` annotation on the advertise-map leaf tells the parser that from that leaf and onward the ordering is no longer important and the leaves can be entered in any order (and leaves can be skipped).
-
-Two other annotations are often used in combination with `tailf:cli-sequence-commands`; `tailf:cli-reset-all-siblings`, and `tailf:cli-compact-syntax`. The first tells the parser that all leaves should be reset when any leaf is entered, i.e. if the user first gives the command:
-
-```
-aggregate-address 1.1.1.1 255.255.255.0 as-set summary-only
-```
-
-This would result in the leaves address, mask, as-set, and summary-only being set in the configuration. However, if the user then entered:
-
-```
-aggregate-address 1.1.1.1 255.255.255.0 as-set
-```
-
-The assumed result of this is that summary-only is no longer configured, ie that all leaves in the container is zeroed out when the command is entered again. The `tailf:cli-compact-syntax` annotation tells the CLI engine to render all leaves in the rendered on a separate line.
-
-```
-aggregate-address 1.1.1.1
-aggregate-address 255.255.255.0
-aggregate-address as-set
-aggregate-address summary-only
-```
-
-The above will be rendered on one line (compact syntax) as:
-
-```
-aggregate-address 1.1.1.1 255.255.255.0 as-set summary-only
-```
-
-
-
-tailf:cli-sequence-commands and tailf:cli-break-sequence-commands
-
-These annotations are used to tell the CLI to only accept leaves in a container in the same order as they appears in the data model. This is typically required when the leaf names are hidden using the `tailf:cli-drop-node-name` annotation. It is very common in the Cisco CLI that commands accept multiple parameters, and such commands must be mapped to setting of multiple leaves in the data model. For example the `aggregate-address` command in the `router bgp` submode:
-
-```
-// router bgp * / aggregate-address
-container aggregate-address {
- tailf:info "Configure BGP aggregate entries";
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands {
- tailf:cli-reset-all-siblings;
- }
- leaf address {
- tailf:cli-drop-node-name;
- type inet:ipv4-address {
- tailf:info "A.B.C.D;;Aggregate address";
- }
- }
- leaf mask {
- tailf:cli-drop-node-name;
- type inet:ipv4-address {
- tailf:info "A.B.C.D;;Aggregate mask";
- }
- }
- leaf advertise-map {
- tailf:cli-break-sequence-commands;
- tailf:info "Set condition to advertise attribute";
- type string {
- tailf:info "WORD;;Route map to control attribute "
- +"advertisement";
- }
- }
- leaf as-set {
- tailf:info "Generate AS set path information";
- type empty;
- }
- leaf attribute-map {
- type string {
- tailf:info "WORD;;Route map for parameter control";
- }
- }
- leaf as-override {
- tailf:info "Override matching AS-number while sending update";
- type empty;
- }
- leaf route-map {
- type string {
- tailf:info "WORD;;Route map for parameter control";
- }
- }
- leaf summary-only {
- tailf:info "Filter more specific routes from updates";
- type empty;
- }
- leaf suppress-map {
- tailf:info "Conditionally filter more specific routes from "
- +"updates";
- type string {
- tailf:info "WORD;;Route map for suppression";
- }
- }
-}
-```
-
-In the above example, the `tailf:cli-sequence-commands` annotation tells the parser to require the leaves in the `aggregate-address` container to be entered in the same order as in the data model, i.e. first address then mask. Since these leaves also have the `tailf:cli-drop-node-name` annotation, it would be impossible for the parser to know which leaf to map the values to, unless the order of appearance was used. The `tailf:cli-break-sequence-commands` annotation on the advertise-map leaf tells the parser that from that leaf and onward the ordering is no longer important and the leaves can be entered in any order (and leaves can be skipped).
-
-Two other annotations are often used in combination with `tailf:cli-sequence-commands`; `tailf:cli-reset-all-siblings`, and `tailf:cli-compact-syntax`. The first tells the parser that all leaves should be reset when any leaf is entered, i.e. if the user first gives the command:
-
-```
-aggregate-address 1.1.1.1 255.255.255.0 as-set summary-only
-```
-
-This would result in the leaves address, mask, as-set, and summary-only being set in the configuration. However, if the user then entered:
-
-```
-aggregate-address 1.1.1.1 255.255.255.0 as-set
-```
-
-The assumed result of this is that summary-only is no longer configured, ie that all leaves in the container is zeroed out when the command is entered again. The `tailf:cli-compact-syntax` annotation tells the CLI engine to render all leaves in the rendered on a separate line.
-
-```
-aggregate-address 1.1.1.1
-aggregate-address 255.255.255.0
-aggregate-address as-set
-aggregate-address summary-only
-```
-
-The above will be rendered on one line (compact syntax) as:
-
-```
-aggregate-address 1.1.1.1 255.255.255.0 as-set summary-only
-```
-
-
-
-
-
-Tells the parser that this particular leaf should be allowed to be entered in case insensitive format. The reason this is needed is that some devices display a command in one case, and other display the same command in a different case. Normally command parsing is case-sensitive. For example:
-
-```yang
-leaf dhcp {
- tailf:info "Default Gateway obtained from DHCP";
- tailf:cli-case-insensitive;
- type empty;
-}
-```
-
-
-
-tailf:cli-case-insensitive
-
-Tells the parser that this particular leaf should be allowed to be entered in case insensitive format. The reason this is needed is that some devices display a command in one case, and other display the same command in a different case. Normally command parsing is case-sensitive. For example:
-
-```yang
-leaf dhcp {
- tailf:info "Default Gateway obtained from DHCP";
- tailf:cli-case-insensitive;
- type empty;
-}
-```
-
-
-
-
-
-This annotation tells the CLI engine to render all leaves in the container on one command line, i.e. instead of the default rendering where each leaf is rendered on a separate line
-
-```
-aggregate-address 1.1.1.1
-aggregate-address 255.255.255.0
-aggregate-address as-set
-aggregate-address summary-only
-```
-
-It should be rendered on one line (compact syntax) as
-
-```
-aggregate-address 1.1.1.1 255.255.255.0 as-set summary-only
-```
-
-
-
-tailf:cli-compact-syntax
-
-This annotation tells the CLI engine to render all leaves in the container on one command line, i.e. instead of the default rendering where each leaf is rendered on a separate line
-
-```
-aggregate-address 1.1.1.1
-aggregate-address 255.255.255.0
-aggregate-address as-set
-aggregate-address summary-only
-```
-
-It should be rendered on one line (compact syntax) as
-
-```
-aggregate-address 1.1.1.1 255.255.255.0 as-set summary-only
-```
-
-
-
-
-
-Deleting items in the database is tricky when using the Cisco CLI syntax. The reason is that `no ` is open to multiple interpretations in many cases, for example when multiple leaves are set in one command, or a presence container is set in addition to a leaf. For example:
-
-```yang
-container dampening {
- tailf:info "Enable event dampening";
- presence "true";
- leaf dampening-time {
- tailf:cli-drop-node-name;
- tailf:cli-delete-container-on-delete;
- tailf:info "<1-30>;;Half-life time for penalty";
- type uint16 {
- range 1..30;
- }
- }
-}
-```
-
-This data model allows both the `dampening` command and the command `dampening 10`. When the command `no dampening 10` is issued, should both the dampening container and the leaf be removed, or only the leaf? The `tailf:cli-delete-container-on-delete` tells the CLI engine to also delete the container when the leaf is removed.
-
-
-
-tailf:cli-delete-container-on-delete
-
-Deleting items in the database is tricky when using the Cisco CLI syntax. The reason is that `no
-
-
-
-This annotation tells the CLI engine to remove a list entry or a presence container when all content of the container or list instance has been removed. For example:
-
-```yang
-container access-class {
- tailf:info "Filter connections based on an IP access list";
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands;
- tailf:cli-reset-container;
- tailf:cli-flatten-container;
- list access-list {
- tailf:cli-drop-node-name;
- tailf:cli-compact-syntax;
- tailf:cli-reset-container;
- tailf:cli-suppress-mode;
- tailf:cli-delete-when-empty;
- key direction;
- leaf direction {
- type enumeration {
- enum "in" {
- tailf:info "Filter incoming connections";
- }
- enum "out" {
- tailf:info "Filter outgoing connections";
- }
- }
- }
- leaf access-list {
- tailf:cli-drop-node-name;
- tailf:cli-prefix-key;
- type exp-ip-acl-type;
- mandatory true;
- }
- leaf vrf-also {
- tailf:info "Same access list is applied for all VRFs";
- type empty;
- }
- }
-}
-```
-
-In this case, the `tailf:cli-delete-when-empty` annotation tells the CLI engine to remove an access-list instance when it doesn't have neither an access-list nor a `vrf-also` child.
-
-
-
-tailf:cli-delete-when-empty
-
-This annotation tells the CLI engine to remove a list entry or a presence container when all content of the container or list instance has been removed. For example:
-
-```yang
-container access-class {
- tailf:info "Filter connections based on an IP access list";
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands;
- tailf:cli-reset-container;
- tailf:cli-flatten-container;
- list access-list {
- tailf:cli-drop-node-name;
- tailf:cli-compact-syntax;
- tailf:cli-reset-container;
- tailf:cli-suppress-mode;
- tailf:cli-delete-when-empty;
- key direction;
- leaf direction {
- type enumeration {
- enum "in" {
- tailf:info "Filter incoming connections";
- }
- enum "out" {
- tailf:info "Filter outgoing connections";
- }
- }
- }
- leaf access-list {
- tailf:cli-drop-node-name;
- tailf:cli-prefix-key;
- type exp-ip-acl-type;
- mandatory true;
- }
- leaf vrf-also {
- tailf:info "Same access list is applied for all VRFs";
- type empty;
- }
- }
-}
-```
-
-In this case, the `tailf:cli-delete-when-empty` annotation tells the CLI engine to remove an access-list instance when it doesn't have neither an access-list nor a `vrf-also` child.
-
-
-
-
-
-This annotation tells the CLI engine that there is a dependency between the current account when generating diff commands to send to the device, or when rendering the `show configuration` command output. It can have two different substatements: `tailf:cli-trigger-on-set` and `tailf:cli-trigger-on-all`.
-
-Without substatements, it should be thought of as similar to a leaf-ref, i.e. if the dependency target is delete, first perform any modifications to this leaf. For example, the redistribute `ospf` submode in `router bgp`:
-
-```
-// router bgp * / redistribute ospf *
-list ospf {
- tailf:info "Open Shortest Path First (OSPF)";
- tailf:cli-suppress-mode;
- tailf:cli-delete-when-empty;
- tailf:cli-compact-syntax;
- key id;
- leaf id {
- type uint16 {
- tailf:info "<1-65535>;;Process ID";
- range "1..65535";
- }
- }
- list vrf {
- tailf:info "VPN Routing/Forwarding Instance";
- tailf:cli-suppress-mode;
- tailf:cli-delete-when-empty;
- tailf:cli-compact-syntax;
- tailf:cli-diff-dependency "/ios:ip/ios:vrf";
- tailf:cli-diff-dependency "/ios:vrf/ios:definition";
- key name;
- leaf name {
- type string {
- tailf:info "WORD;;VPN Routing/Forwarding Instance (VRF) name";
- }
- }
- }
-}
-```
-
-The `tailf:cli-diff-dependency "/ios:ip/ios:vrf"` tells the engine that if the `ip vrf` part of the configuration is deleted, then first display any changes to this part. This can be used when the device requires a certain ordering of the commands.
-
-If the `tailf:cli-trigger-on-all` substatement is used, then it means that the target will always be displayed before the current node. Normally the order in the YANG file is used, but and it might not even be possible if they are embedded in a container.
-
-The `tailf:cli-trigger-on-set` tells the engine that the ordering should be taken into account when this leaf is set and some other leaf is deleted. The other leaf should then be deleted before this is set. Suppose you have this data model:
-
-```yang
-list b {
- key "id";
- leaf id {
- type string;
- }
- leaf name {
- type string;
- }
- leaf y {
- type string;
- }
-}
-list a {
- key id;
- leaf id {
- tailf:cli-diff-dependency "/c[id=current()/../id]" {
- tailf:cli-trigger-on-set;
- }
- tailf:cli-diff-dependency "/b[id=current()/../id]";
- type string;
- }
-}
-list c {
- key id;
- leaf id {
- tailf:cli-diff-dependency "/a[id=current()/../id]" {
- tailf:cli-trigger-on-set;
- }
- tailf:cli-diff-dependency "/b[id=current()/../id]";
- type string;
- }
-}
-```
-
-Then the `tailf:cli-diff-dependency "/b[id=current()/../id]"` tells the CLI that before `b` list instance is delete, the `c` instance with the same name needs to be changed.
-
-```
-tailf:cli-diff-dependency "/a[id=current()/../id]" {
- tailf:cli-trigger-on-set;
-}
-```
-
-This annotation, on the other hand, says that before this instance is created any changes to the a instance with the same name needs to be displayed.
-
-Suppose you have the configuration:
-
-```
-b foo
-!
-a foo
-!
-```
-
-Then created `c foo` and deleted `a foo`, it should be displayed as:
-
-```
-no a foo
-c foo
-```
-
-If you then deleted **c foo** and created **a foo**, it should be rendered as:
-
-```
-no c foo
-a foo
-```
-
-That is, in the reverse order.
-
-
-
-tailf:cli-diff-dependency
-
-This annotation tells the CLI engine that there is a dependency between the current account when generating diff commands to send to the device, or when rendering the `show configuration` command output. It can have two different substatements: `tailf:cli-trigger-on-set` and `tailf:cli-trigger-on-all`.
-
-Without substatements, it should be thought of as similar to a leaf-ref, i.e. if the dependency target is delete, first perform any modifications to this leaf. For example, the redistribute `ospf` submode in `router bgp`:
-
-```
-// router bgp * / redistribute ospf *
-list ospf {
- tailf:info "Open Shortest Path First (OSPF)";
- tailf:cli-suppress-mode;
- tailf:cli-delete-when-empty;
- tailf:cli-compact-syntax;
- key id;
- leaf id {
- type uint16 {
- tailf:info "<1-65535>;;Process ID";
- range "1..65535";
- }
- }
- list vrf {
- tailf:info "VPN Routing/Forwarding Instance";
- tailf:cli-suppress-mode;
- tailf:cli-delete-when-empty;
- tailf:cli-compact-syntax;
- tailf:cli-diff-dependency "/ios:ip/ios:vrf";
- tailf:cli-diff-dependency "/ios:vrf/ios:definition";
- key name;
- leaf name {
- type string {
- tailf:info "WORD;;VPN Routing/Forwarding Instance (VRF) name";
- }
- }
- }
-}
-```
-
-The `tailf:cli-diff-dependency "/ios:ip/ios:vrf"` tells the engine that if the `ip vrf` part of the configuration is deleted, then first display any changes to this part. This can be used when the device requires a certain ordering of the commands.
-
-If the `tailf:cli-trigger-on-all` substatement is used, then it means that the target will always be displayed before the current node. Normally the order in the YANG file is used, but and it might not even be possible if they are embedded in a container.
-
-The `tailf:cli-trigger-on-set` tells the engine that the ordering should be taken into account when this leaf is set and some other leaf is deleted. The other leaf should then be deleted before this is set. Suppose you have this data model:
-
-```yang
-list b {
- key "id";
- leaf id {
- type string;
- }
- leaf name {
- type string;
- }
- leaf y {
- type string;
- }
-}
-list a {
- key id;
- leaf id {
- tailf:cli-diff-dependency "/c[id=current()/../id]" {
- tailf:cli-trigger-on-set;
- }
- tailf:cli-diff-dependency "/b[id=current()/../id]";
- type string;
- }
-}
-list c {
- key id;
- leaf id {
- tailf:cli-diff-dependency "/a[id=current()/../id]" {
- tailf:cli-trigger-on-set;
- }
- tailf:cli-diff-dependency "/b[id=current()/../id]";
- type string;
- }
-}
-```
-
-Then the `tailf:cli-diff-dependency "/b[id=current()/../id]"` tells the CLI that before `b` list instance is delete, the `c` instance with the same name needs to be changed.
-
-```
-tailf:cli-diff-dependency "/a[id=current()/../id]" {
- tailf:cli-trigger-on-set;
-}
-```
-
-This annotation, on the other hand, says that before this instance is created any changes to the a instance with the same name needs to be displayed.
-
-Suppose you have the configuration:
-
-```
-b foo
-!
-a foo
-!
-```
-
-Then created `c foo` and deleted `a foo`, it should be displayed as:
-
-```
-no a foo
-c foo
-```
-
-If you then deleted **c foo** and created **a foo**, it should be rendered as:
-
-```
-no c foo
-a foo
-```
-
-That is, in the reverse order.
-
-
-
-
-
-This annotation is used to disambiguate parsing. This is sometimes necessary when `tailf:cli-drop-node-name` is used. For example:
-
-```yang
-container authentication {
- tailf:info "Authentication";
- choice auth {
- leaf word {
- tailf:cli-drop-node-name;
- tailf:cli-disallow-value "md5|text";
- type string {
- tailf:info "WORD;;Plain text authentication string "
- +"(8 chars max)";
- }
- }
- container md5 {
- tailf:info "Use MD5 authentication";
- leaf key-chain {
- tailf:info "Set key chain";
- type string {
- tailf:info "WORD;;Name of key-chain";
- }
- }
- }
- }
-}
-```
-
-when the command `authentication md5...` is entered the CLI parser cannot determine if the leaf **word** should be set to the value `"md5"` of if the leaf `md5` should be set. By adding the `tailf:cli-disallow-value` annotation you can tell the CLI parser that certain regular expressions are not valid values. An alternative would be to add a restriction to the string type of **word** but this is much more difficult since restrictions can only be used to specify allowed values, not disallowed values.
-
-
-
-tailf:cli-disallow-value
-
-This annotation is used to disambiguate parsing. This is sometimes necessary when `tailf:cli-drop-node-name` is used. For example:
-
-```yang
-container authentication {
- tailf:info "Authentication";
- choice auth {
- leaf word {
- tailf:cli-drop-node-name;
- tailf:cli-disallow-value "md5|text";
- type string {
- tailf:info "WORD;;Plain text authentication string "
- +"(8 chars max)";
- }
- }
- container md5 {
- tailf:info "Use MD5 authentication";
- leaf key-chain {
- tailf:info "Set key chain";
- type string {
- tailf:info "WORD;;Name of key-chain";
- }
- }
- }
- }
-}
-```
-
-when the command `authentication md5...` is entered the CLI parser cannot determine if the leaf **word** should be set to the value `"md5"` of if the leaf `md5` should be set. By adding the `tailf:cli-disallow-value` annotation you can tell the CLI parser that certain regular expressions are not valid values. An alternative would be to add a restriction to the string type of **word** but this is much more difficult since restrictions can only be used to specify allowed values, not disallowed values.
-
-
-
-
-
-See the description of `tailf:cli-allow-join-with-value` and `tailf:cli-allow-join-with-key`.
-
-
-
-tailf:cli-display-joined
-
-See the description of `tailf:cli-allow-join-with-value` and `tailf:cli-allow-join-with-key`.
-
-
-
-
-
-This annotation can be used on a presence container and tells the CLI engine that the container should be displayed as a separate command, even when a leaf in the container is set. The default rendering does not do this. For example:
-
-```yang
-container ntp {
- tailf:info "Configure NTP";
- // interface * / ntp broadcast
- container broadcast {
- tailf:info "Configure NTP broadcast service";
- //tailf:cli-display-separated;
- presence true;
- container client {
- tailf:info "Listen to NTP broadcasts";
- tailf:cli-full-command;
- presence true;
- }
- }
-}
-```
-
-If both `broadcast` and `client` are created in the configuration then this will be displayed as:
-
-```
-ntp broadcast
-ntp broadcast client
-```
-
-When the `tailf:cli-display-separated` annotation is used. If the annotation isn't present then it would only be displayed as:
-
-```
-ntp broadcast client
-```
-
-The creation of the broadcast container would be implied.
-
-
-
-tailf:cli-display-separated
-
-This annotation can be used on a presence container and tells the CLI engine that the container should be displayed as a separate command, even when a leaf in the container is set. The default rendering does not do this. For example:
-
-```yang
-container ntp {
- tailf:info "Configure NTP";
- // interface * / ntp broadcast
- container broadcast {
- tailf:info "Configure NTP broadcast service";
- //tailf:cli-display-separated;
- presence true;
- container client {
- tailf:info "Listen to NTP broadcasts";
- tailf:cli-full-command;
- presence true;
- }
- }
-}
-```
-
-If both `broadcast` and `client` are created in the configuration then this will be displayed as:
-
-```
-ntp broadcast
-ntp broadcast client
-```
-
-When the `tailf:cli-display-separated` annotation is used. If the annotation isn't present then it would only be displayed as:
-
-```
-ntp broadcast client
-```
-
-The creation of the broadcast container would be implied.
-
-
-
-
-
-This might be the most used annotation of them all. It can be used for multiple purposes. Primarily it tells the CLI engine that the node name should be ignored, which is typically needed when there is no corresponding leaf name in the command, typically when a command requires multiple parameters:
-
-```yang
-container exec-timeout {
- tailf:info "Set the EXEC timeout";
- tailf:cli-sequence-commands;
- tailf:cli-compact-syntax;
- leaf minutes {
- tailf:info "<0-35791>;;Timeout in minutes";
- tailf:cli-drop-node-name;
- type uint32;
- }
- leaf seconds {
- tailf:info "<0-2147483>;;Timeout in seconds";
- tailf:cli-drop-node-name;
- type uint32;
- }
-}
-```
-
-However, it can also be used to introduce ambiguity, or a choice in the parse tree if you like. Suppose you need to support these commands:
-
-```
-// interface * / vrf forwarding
-// interface * / ip vrf forwarding
-choice vrf-choice {
- container ip-vrf {
- tailf:cli-no-keyword;
- tailf:cli-drop-node-name;
- container ip {
- container vrf {
- leaf forwarding {
- tailf:info "Configure forwarding table";
- type string {
- tailf:info "WORD;;VRF name";
- }
- tailf:non-strict-leafref {
- path "/ios:ip/ios:vrf/ios:name";
- }
- }
- }
- }
-}
-container vrf {
- tailf:info "VPN Routing/Forwarding parameters on the interface";
- // interface * / vrf forwarding
- leaf forwarding {
- tailf:info "Configure forwarding table";
- type string {
- tailf:info "WORD;;VRF name";
- }
- tailf:non-strict-leafref {
- path "/ios:vrf/ios:definition/ios:name";
- }
- }
-}
-
-// interface * / ip
-container ip {
- tailf:info "Interface Internet Protocol config commands";
-}
-```
-
-In the above case, when the parser sees the beginning of the command `ip`, it can interpret it as either entering the `interface */vrf-choice/ip-vrf/ip/vrf` config tree, or the `interface */ip` tree since the tokens consumed are the same in both branches. When the parser sees a `tailf:cli-drop-node-name` in the parse tree, it will try to match the current token stream to that parse tree, and if that fails backtrack and try other paths.
-
-
-
-tailf:cli-drop-node-name
-
-This might be the most used annotation of them all. It can be used for multiple purposes. Primarily it tells the CLI engine that the node name should be ignored, which is typically needed when there is no corresponding leaf name in the command, typically when a command requires multiple parameters:
-
-```yang
-container exec-timeout {
- tailf:info "Set the EXEC timeout";
- tailf:cli-sequence-commands;
- tailf:cli-compact-syntax;
- leaf minutes {
- tailf:info "<0-35791>;;Timeout in minutes";
- tailf:cli-drop-node-name;
- type uint32;
- }
- leaf seconds {
- tailf:info "<0-2147483>;;Timeout in seconds";
- tailf:cli-drop-node-name;
- type uint32;
- }
-}
-```
-
-However, it can also be used to introduce ambiguity, or a choice in the parse tree if you like. Suppose you need to support these commands:
-
-```
-// interface * / vrf forwarding
-// interface * / ip vrf forwarding
-choice vrf-choice {
- container ip-vrf {
- tailf:cli-no-keyword;
- tailf:cli-drop-node-name;
- container ip {
- container vrf {
- leaf forwarding {
- tailf:info "Configure forwarding table";
- type string {
- tailf:info "WORD;;VRF name";
- }
- tailf:non-strict-leafref {
- path "/ios:ip/ios:vrf/ios:name";
- }
- }
- }
- }
-}
-container vrf {
- tailf:info "VPN Routing/Forwarding parameters on the interface";
- // interface * / vrf forwarding
- leaf forwarding {
- tailf:info "Configure forwarding table";
- type string {
- tailf:info "WORD;;VRF name";
- }
- tailf:non-strict-leafref {
- path "/ios:vrf/ios:definition/ios:name";
- }
- }
-}
-
-// interface * / ip
-container ip {
- tailf:info "Interface Internet Protocol config commands";
-}
-```
-
-In the above case, when the parser sees the beginning of the command `ip`, it can interpret it as either entering the `interface */vrf-choice/ip-vrf/ip/vrf` config tree, or the `interface */ip` tree since the tokens consumed are the same in both branches. When the parser sees a `tailf:cli-drop-node-name` in the parse tree, it will try to match the current token stream to that parse tree, and if that fails backtrack and try other paths.
-
-
-
-
-
-Tells the CLI engine to add an explicit exit command in the current submode. Normally, a submode does not have exit commands for leaving a submode, instead, it is implied by the following command residing in a parent mode. However, to avoid ambiguity it is sometimes necessary. For example, in the `address-family` submode:
-
-```yang
-container address-family {
- tailf:info "Enter Address Family command mode";
- container ipv6 {
- tailf:info "Address family";
- container unicast {
- tailf:cli-add-mode;
- tailf:cli-mode-name "config-router-af";
- tailf:info "Address Family Modifier";
- tailf:cli-full-command;
- tailf:cli-exit-command "exit-address-family" {
- tailf:info "Exit from Address Family configuration "
- +"mode";
- }
- }
- }
-}
-```
-
-
-
-tailf:cli-exit-command
-
-Tells the CLI engine to add an explicit exit command in the current submode. Normally, a submode does not have exit commands for leaving a submode, instead, it is implied by the following command residing in a parent mode. However, to avoid ambiguity it is sometimes necessary. For example, in the `address-family` submode:
-
-```yang
-container address-family {
- tailf:info "Enter Address Family command mode";
- container ipv6 {
- tailf:info "Address family";
- container unicast {
- tailf:cli-add-mode;
- tailf:cli-mode-name "config-router-af";
- tailf:info "Address Family Modifier";
- tailf:cli-full-command;
- tailf:cli-exit-command "exit-address-family" {
- tailf:info "Exit from Address Family configuration "
- +"mode";
- }
- }
- }
-}
-```
-
-
-
-
-
-This tells the CLI engine to render explicit exit commands instead of the default `!` when leaving a submode. The annotation is inherited by all submodes. For example:
-
-```yang
-container interface {
- tailf:info "Configure interfaces";
- tailf:cli-diff-dependency "/ios:vrf";
- tailf:cli-explicit-exit;
- // interface Loopback
- list Loopback {
- tailf:info "Loopback interface";
- tailf:cli-allow-join-with-key {
- tailf:cli-display-joined;
- }
- tailf:cli-mode-name "config-if";
- tailf:cli-suppress-key-abbreviation;
- // tailf:cli-full-command;
- key name;
- leaf name {
- type string {
- pattern "([0-9\.])+";
- tailf:info "<0-2147483647>;;Loopback interface number";
- }
- }
- uses interface-common-grouping;
- }
-}
-```
-
-Without the `tailf:cli-explicit-exit` annotation, the edit sequences sent to the NED device will contain `!` at the end of a mode, and rely on the next command to move from one submode to some other place in the CLI. This is the way the Cisco CLI usually works. However, it may cause problems if the next edit command is also a valid command in the current submode. Using `tailf:cli-explicit-exit` gets around this problem.
-
-
-
-tailf:cli-explicit-exit
-
-This tells the CLI engine to render explicit exit commands instead of the default `!` when leaving a submode. The annotation is inherited by all submodes. For example:
-
-```yang
-container interface {
- tailf:info "Configure interfaces";
- tailf:cli-diff-dependency "/ios:vrf";
- tailf:cli-explicit-exit;
- // interface Loopback
- list Loopback {
- tailf:info "Loopback interface";
- tailf:cli-allow-join-with-key {
- tailf:cli-display-joined;
- }
- tailf:cli-mode-name "config-if";
- tailf:cli-suppress-key-abbreviation;
- // tailf:cli-full-command;
- key name;
- leaf name {
- type string {
- pattern "([0-9\.])+";
- tailf:info "<0-2147483647>;;Loopback interface number";
- }
- }
- uses interface-common-grouping;
- }
-}
-```
-
-Without the `tailf:cli-explicit-exit` annotation, the edit sequences sent to the NED device will contain `!` at the end of a mode, and rely on the next command to move from one submode to some other place in the CLI. This is the way the Cisco CLI usually works. However, it may cause problems if the next edit command is also a valid command in the current submode. Using `tailf:cli-explicit-exit` gets around this problem.
-
-
-
-
-
-By default, the key leaf names are not shown in the CLI, but sometimes you want them to be visible, for example:
-
-```
-// ip explicit-path name *
-list explicit-path {
- tailf:info "Configure explicit-path";
- tailf:cli-mode-name "cfg-ip-expl-path";
- key name;
- leaf name {
- tailf:info "Specify explicit path by name";
- tailf:cli-expose-key-name;
- type string {
- tailf:info "WORD;;Enter name";
- }
- }
-}
-```
-
-
-
-tailf:cli-expose-key-name
-
-By default, the key leaf names are not shown in the CLI, but sometimes you want them to be visible, for example:
-
-```
-// ip explicit-path name *
-list explicit-path {
- tailf:info "Configure explicit-path";
- tailf:cli-mode-name "cfg-ip-expl-path";
- key name;
- leaf name {
- tailf:info "Specify explicit path by name";
- tailf:cli-expose-key-name;
- type string {
- tailf:info "WORD;;Enter name";
- }
- }
-}
-```
-
-
-
-
-
-By default, a leaf-list is rendered as a single line with the elements enclosed by `[` and `]`. If you want the values to be listed on one line this is the annotation to use. For example:
-
-```
-// class-map * / match cos
-leaf-list cos {
- tailf:info "IEEE 802.1Q/ISL class of service/user priority values";
- tailf:cli-flat-list-syntax;
- type uint16 {
- range "0..7";
- tailf:info "<0-7>;;Enter up to 4 class-of-service values"+
- " separated by white-spaces";
- }
-}
-```
-
-
-
-tailf:cli-flat-list-syntax
-
-By default, a leaf-list is rendered as a single line with the elements enclosed by `[` and `]`. If you want the values to be listed on one line this is the annotation to use. For example:
-
-```
-// class-map * / match cos
-leaf-list cos {
- tailf:info "IEEE 802.1Q/ISL class of service/user priority values";
- tailf:cli-flat-list-syntax;
- type uint16 {
- range "0..7";
- tailf:info "<0-7>;;Enter up to 4 class-of-service values"+
- " separated by white-spaces";
- }
-}
-```
-
-
-
-
-
-This annotation is a bit tricky. It tells the CLI engine that the container should be allowed to co-exist with leaves on the same command line, i.e. flattened. Normally, once the parser has entered a container it will not exit. However, if the container is flattened, the container will be exited once all leaves in the container have been entered. Also, a flattened container will be displayed together with sibling leaves on the same command line (provided the surrounding container has `tailf:cli-compact-syntax`).
-
-Suppose you want to model the command `limit [inbound ] [outbound ] mtu `. In other words, the inbound and outbound settings are optional, but if you give inbound you have to specify two 16-bit integers, and you can always specify mtu.
-
-```yang
-container foo {
- tailf:cli-compact-syntax;
- container inbound {
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands;
- tailf:cli-flatten-container;
- leaf a {
- tailf:cli-drop-node-name;
- type uint16;
- }
- leaf b {
- tailf:cli-drop-node-name;
- type uint16;
- }
- }
- container outbound {
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands;
- tailf:cli-flatten-container;
- leaf a {
- tailf:cli-drop-node-name;
- type uint16;
- }
- leaf b {
- tailf:cli-drop-node-name;
- type uint16;
- }
- }
- leaf mtu {
- type uint16;
- }
-}
-```
-
-In the above example the `tailf:cli-flatten-container` tells the parser that it should exit the outbound/inbound container once both values have been entered. Without the annotation, it would not be possible to exit the container once it has been entered. It would be possible to have the command `foo inbound 1 3` or `foo outbound 1 2` but not both at the same time, and not the final mtu leaf. The `tailf:cli-compact-syntax` annotation tells the renderer to display all leaves on the same line. If it wasn't used the line setting `foo inbound 1 2 outbound 3 4 mtu 1500` would be displayed as:
-
-```
-foo inbound 1
-foo inbound 2
-foo outbound 3
-foo outbound 4
-foo mtu 1500
-```
-
-The annotation `tailf:cli-sequence-commands` tells the CLI that the user has to enter the leaves inside the container in the specified order. Without this annotation, it would not be possible to drop the names of the leaves and still have a deterministic parser. With the annotation, the parser knows that for the command `foo inbound 1 2`, leaf a should be assigned the value 1 and leaf b the value 2.
-
-Another example:
-
-```yang
-container htest {
- tailf:cli-add-mode;
- container param {
- tailf:cli-hide-in-submode;
- tailf:cli-flatten-container;
- tailf:cli-compact-syntax;
- leaf a {
- type uint16;
- }
- leaf b {
- type uint16;
- }
- }
- leaf mtu {
- type uint16;
- }
-}
-```
-
-The above model results in the command `htest param a b ` for entering the submode. Once the submode has been entered, the command `mtu ` is available. Without the `tailf:cli-flatten-container` annotation it wouldn't be possible to use the `tailf:cli-hide-in-submode` annotation to attach the leaves to the command for entering the submode.
-
-
-
-tailf:cli-flatten-container
-
-This annotation is a bit tricky. It tells the CLI engine that the container should be allowed to co-exist with leaves on the same command line, i.e. flattened. Normally, once the parser has entered a container it will not exit. However, if the container is flattened, the container will be exited once all leaves in the container have been entered. Also, a flattened container will be displayed together with sibling leaves on the same command line (provided the surrounding container has `tailf:cli-compact-syntax`).
-
-Suppose you want to model the command `limit [inbound
-
-
-
-This annotation tells the parser to not accept any more input beyond this element. By default, the parser will allow the setting of multiple leaves in the same command, and both enter a submode and set leaf values in the submode. In most cases, it doesn't matter that the parser accepts commands that are not actually generated by the device in the output of `show running-config`. It is however needed to avoid ambiguity, or just to make the NSO CLI for the device more user-friendly.
-
-```yang
-container transceiver {
- tailf:info "Select from transceiver configuration commands";
- container "type" {
- tailf:info "type keyword";
- // transceiver type all
- container all {
- tailf:cli-add-mode;
- tailf:cli-mode-name "config-xcvr-type";
- tailf:cli-full-command;
- // transceiver type all / monitoring
- container monitoring {
- tailf:info "Enable/disable monitoring";
- presence true;
- leaf interval {
- tailf:info "Set interval for monitoring";
- type uint16 {
- tailf:info "<300-3600>;;Time interval for monitoring "+
- "transceiver in seconds";
- range "300..3600";
- }
- }
- }
- }
- }
-}
-```
-
-In the above example, it is possible to have the command `transceiver type all` for entering a submode, and then give the command `monitor [interval <300-3600>]`. If the `tailf:cli-full-command` annotation had not been used, the following would also have been a valid command: `transceiver type all monitor [interval <300-3600>]`. In the above example, it doesn't make a difference as far as being able to parse the configuration on a device. The device will never show the oneline command syntax but always display it as two lines, one for entering the submode and one for setting the monitor interval.
-
-
-
-tailf:cli-full-command
-
-This annotation tells the parser to not accept any more input beyond this element. By default, the parser will allow the setting of multiple leaves in the same command, and both enter a submode and set leaf values in the submode. In most cases, it doesn't matter that the parser accepts commands that are not actually generated by the device in the output of `show running-config`. It is however needed to avoid ambiguity, or just to make the NSO CLI for the device more user-friendly.
-
-```yang
-container transceiver {
- tailf:info "Select from transceiver configuration commands";
- container "type" {
- tailf:info "type keyword";
- // transceiver type all
- container all {
- tailf:cli-add-mode;
- tailf:cli-mode-name "config-xcvr-type";
- tailf:cli-full-command;
- // transceiver type all / monitoring
- container monitoring {
- tailf:info "Enable/disable monitoring";
- presence true;
- leaf interval {
- tailf:info "Set interval for monitoring";
- type uint16 {
- tailf:info "<300-3600>;;Time interval for monitoring "+
- "transceiver in seconds";
- range "300..3600";
- }
- }
- }
- }
- }
-}
-```
-
-In the above example, it is possible to have the command `transceiver type all` for entering a submode, and then give the command `monitor [interval <300-3600>]`. If the `tailf:cli-full-command` annotation had not been used, the following would also have been a valid command: `transceiver type all monitor [interval <300-3600>]`. In the above example, it doesn't make a difference as far as being able to parse the configuration on a device. The device will never show the oneline command syntax but always display it as two lines, one for entering the submode and one for setting the monitor interval.
-
-
-
-
-
-This annotation tells the CLI parser that no further arguments should be accepted for this path when the path is traversed as an argument to the **no** command.
-
-Example of use:
-
-```
-// event manager applet * / action * info
-container info {
- tailf:info "Obtain system specific information";
- // event manager applet * / action info type
- container "type" {
- tailf:info "Type of information to obtain";
- tailf:cli-full-no;
- container snmp {
- tailf:info "SNMP information";
- // event manager applet * / action info type snmp var
- container var {
- tailf:info "Trap variable";
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands;
- tailf:cli-reset-container;
- leaf variable-name {
- tailf:cli-drop-node-name;
- tailf:cli-incomplete-command;
- type string {
- tailf:info "WORD;;Trap variable name";
- }
- }
- }
- }
- }
-}
-```
-
-
-
-tailf:cli-full-no
-
-This annotation tells the CLI parser that no further arguments should be accepted for this path when the path is traversed as an argument to the **no** command.
-
-Example of use:
-
-```
-// event manager applet * / action * info
-container info {
- tailf:info "Obtain system specific information";
- // event manager applet * / action info type
- container "type" {
- tailf:info "Type of information to obtain";
- tailf:cli-full-no;
- container snmp {
- tailf:info "SNMP information";
- // event manager applet * / action info type snmp var
- container var {
- tailf:info "Trap variable";
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands;
- tailf:cli-reset-container;
- leaf variable-name {
- tailf:cli-drop-node-name;
- tailf:cli-incomplete-command;
- type string {
- tailf:info "WORD;;Trap variable name";
- }
- }
- }
- }
- }
-}
-```
-
-
-
-
-
-In some cases, you need to give some parameters for entering a submode, but the submode cannot be modeled as a list, or the parameters should not be modeled as a key element of the list but rather behaves as a leaf. In these cases, you model the parameter as a leaf and use the `tailf:cli-hide-in-submode` annotation. It has two purposes, the leaf is displayed as part of the command for entering the submode when rendering the config, and the leaf is not available as a command in the submode.
-
-For example:
-
-```
-// event manager applet *
-list applet {
- tailf:info "Register an Event Manager applet";
- tailf:cli-mode-name "config-applet";
- tailf:cli-exit-command "exit" {
- tailf:info "Exit from Event Manager applet configuration submode";
- }
- key name;
- leaf name {
- type string {
- tailf:info "WORD;;Name of the Event Manager applet";
- }
- }
- // event manager applet * authorization
- leaf authorization {
- tailf:info "Specify an authorization type for the applet";
- tailf:cli-hide-in-submode;
- type enumeration {
- enum bypass {
- tailf:info "EEM aaa authorization type bypass";
- }
- }
- }
- // event manager applet * class
- leaf class {
- tailf:info "Specify a class for the applet";
- tailf:cli-hide-in-submode;
- type string {
- tailf:info "Class A-Z | default - default class";
- pattern "[A-Z]|default";
- }
- }
- // event manager applet * trap
- leaf trap {
- tailf:info "Generate an SNMP trap when applet is triggered.";
- tailf:cli-hide-in-submode;
- type empty;
- }
-}
-```
-
-In the example above the key to the list is the **name** leaf, but to enter the submode the user may also give the arguments `event manager applet [authorization bypass] [class ] [trap]`. It is clear that these leaves are not keys to the list since giving the same name but different authorization, class, or trap argument does not result in a new applet instance.
-
-
-
-tailf:cli-hide-in-submode
-
-In some cases, you need to give some parameters for entering a submode, but the submode cannot be modeled as a list, or the parameters should not be modeled as a key element of the list but rather behaves as a leaf. In these cases, you model the parameter as a leaf and use the `tailf:cli-hide-in-submode` annotation. It has two purposes, the leaf is displayed as part of the command for entering the submode when rendering the config, and the leaf is not available as a command in the submode.
-
-For example:
-
-```
-// event manager applet *
-list applet {
- tailf:info "Register an Event Manager applet";
- tailf:cli-mode-name "config-applet";
- tailf:cli-exit-command "exit" {
- tailf:info "Exit from Event Manager applet configuration submode";
- }
- key name;
- leaf name {
- type string {
- tailf:info "WORD;;Name of the Event Manager applet";
- }
- }
- // event manager applet * authorization
- leaf authorization {
- tailf:info "Specify an authorization type for the applet";
- tailf:cli-hide-in-submode;
- type enumeration {
- enum bypass {
- tailf:info "EEM aaa authorization type bypass";
- }
- }
- }
- // event manager applet * class
- leaf class {
- tailf:info "Specify a class for the applet";
- tailf:cli-hide-in-submode;
- type string {
- tailf:info "Class A-Z | default - default class";
- pattern "[A-Z]|default";
- }
- }
- // event manager applet * trap
- leaf trap {
- tailf:info "Generate an SNMP trap when applet is triggered.";
- tailf:cli-hide-in-submode;
- type empty;
- }
-}
-```
-
-In the example above the key to the list is the **name** leaf, but to enter the submode the user may also give the arguments `event manager applet
-
-
-
-Tells the CLI that it should not be possible to hit `cr` after the current element. This is usually the case when a command takes multiple parameters, for example, given the following data model:
-
-```yang
-container foo {
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands;
- presence true;
- leaf a {
- type string;
- }
- leaf b {
- type string;
- }
- leaf c {
- type string;
- }
-}
-```
-
-The valid commands are `foo [a [b [c ]]]`. If it however should be `foo a b [c ]`, i.e. the parameters `a` and `b` are mandatory, and `c` is optional, then the `tailf:cli-incomplete-command` annotation should be used as follows:
-
-```yang
-container foo {
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands;
- tailf:cli-incomplete-command;
- presence true;
- leaf a {
- tailf:cli-incomplete-command;
- type string;
- }
- leaf b {
- type string;
- }
- leaf c {
- type string;
- }
-}
-```
-
-In other words, the command is incomplete after entering just `foo`, and also after entering `foo a `, but not after `foo a b ` or `foo a b c `.
-
-
-
-tailf:cli-incomplete-command
-
-Tells the CLI that it should not be possible to hit `cr` after the current element. This is usually the case when a command takes multiple parameters, for example, given the following data model:
-
-```yang
-container foo {
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands;
- presence true;
- leaf a {
- type string;
- }
- leaf b {
- type string;
- }
- leaf c {
- type string;
- }
-}
-```
-
-The valid commands are `foo [a
-
-
-
-This annotation is similar to the `tailf:cli-incomplete-command` above, but applies to **no** commands. Sometimes you want to prevent the user from entering a generic **no** command. Suppose you have the data model:
-
-```yang
-container foo {
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands;
- tailf:cli-incomplete-command;
- presence true;
- leaf a {
- tailf:cli-incomplete-command;
- type string;
- }
- leaf b {
- type string;
- }
- leaf c {
- type string;
- }
-}
-```
-
-Then it would be valid to write any of the following:
-
-```
-no foo
-no foo a
-no foo a b
-no foo a b c
-```
-
-If you only want the last version of this to be a valid command, then you can use `tailf:cli-incomplete-no` to enforce this. For example:
-
-```yang
-container foo {
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands;
- tailf:cli-incomplete-command;
- tailf:cli-incomplete-no;
- presence true;
- leaf a {
- tailf:cli-incomplete-command;
- tailf:cli-incomplete-no;
- type string;
- }
- leaf b {
- tailf:cli-incomplete-no;
- type string;
- }
- leaf c {
- type string;
- }
-}
-```
-
-
-
-tailf:cli-incomplete-no
-
-This annotation is similar to the `tailf:cli-incomplete-command` above, but applies to **no** commands. Sometimes you want to prevent the user from entering a generic **no** command. Suppose you have the data model:
-
-```yang
-container foo {
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands;
- tailf:cli-incomplete-command;
- presence true;
- leaf a {
- tailf:cli-incomplete-command;
- type string;
- }
- leaf b {
- type string;
- }
- leaf c {
- type string;
- }
-}
-```
-
-Then it would be valid to write any of the following:
-
-```
-no foo
-no foo a
-
-
-
-The default rendering of a leaf-list element is as a command taking a list of values enclosed in square brackets. Given the following element:
-
-```
-// class-map * / source-address
-container source-address {
- tailf:info "Source address";
- leaf-list mac {
- tailf:info "MAC address";
- type string {
- tailf:info "H.H.H;;MAC address";
- }
- }
-}
-```
-
-This would result in the command `source-address mac [ H.H.H... H.H.H ]`, instead of the desired `source-address mac H.H.H`. Given the configuration:
-
-```
-source-address {
- mac [ 1410.9fd8.8999 a110.9fd8.8999 bb10.9fd8.8999 ]
-}
-```
-
-It should be rendered as:
-
-```
-source-address mac 1410.9fd8.8999
-source-address mac a110.9fd8.8999
-source-address mac bb10.9fd8.8999
-```
-
-This is achieved by adding the `tailf:cli-list-syntax` annotation. For example:
-
-```
-// class-map * / source-address
-container source-address {
- tailf:info "Source address";
- leaf-list mac {
- tailf:info "MAC address";
- tailf:cli-list-syntax;
- type string {
- tailf:info "H.H.H;;MAC address";
- }
- }
-}
-```
-
-An alternative would be to model this as a list, i.e.:
-
-```
-// class-map * / source-address
-container source-address {
- tailf:info "Source address";
- list mac {
- tailf:info "MAC address";
- tailf:cli-suppress-mode;
- key address;
- leaf address {
- type string {
- tailf:info "H.H.H;;MAC address";
- }
- }
- }
-}
-```
-
-In many cases, this may be the better choice. Notice how the `tailf:cli-suppress-mode` annotation is used to prevent the list from being rendered as a submode.
-
-
-
-tailf:cli-list-syntax
-
-The default rendering of a leaf-list element is as a command taking a list of values enclosed in square brackets. Given the following element:
-
-```
-// class-map * / source-address
-container source-address {
- tailf:info "Source address";
- leaf-list mac {
- tailf:info "MAC address";
- type string {
- tailf:info "H.H.H;;MAC address";
- }
- }
-}
-```
-
-This would result in the command `source-address mac [ H.H.H... H.H.H ]`, instead of the desired `source-address mac H.H.H`. Given the configuration:
-
-```
-source-address {
- mac [ 1410.9fd8.8999 a110.9fd8.8999 bb10.9fd8.8999 ]
-}
-```
-
-It should be rendered as:
-
-```
-source-address mac 1410.9fd8.8999
-source-address mac a110.9fd8.8999
-source-address mac bb10.9fd8.8999
-```
-
-This is achieved by adding the `tailf:cli-list-syntax` annotation. For example:
-
-```
-// class-map * / source-address
-container source-address {
- tailf:info "Source address";
- leaf-list mac {
- tailf:info "MAC address";
- tailf:cli-list-syntax;
- type string {
- tailf:info "H.H.H;;MAC address";
- }
- }
-}
-```
-
-An alternative would be to model this as a list, i.e.:
-
-```
-// class-map * / source-address
-container source-address {
- tailf:info "Source address";
- list mac {
- tailf:info "MAC address";
- tailf:cli-suppress-mode;
- key address;
- leaf address {
- type string {
- tailf:info "H.H.H;;MAC address";
- }
- }
- }
-}
-```
-
-In many cases, this may be the better choice. Notice how the `tailf:cli-suppress-mode` annotation is used to prevent the list from being rendered as a submode.
-
-
-
-
-
-This annotation is not really needed when writing a NED. It is used to tell the CLI which prompt to use when in the submode. Without specific instructions, the CLI will invent a prompt based on the name of the submode container/list and the list instance. If a specific prompt is desired this annotation can be used. For example:
-
-```yang
-container transceiver {
- tailf:info "Select from transceiver configuration commands";
- container "type" {
- tailf:info "type keyword";
- // transceiver type all
- container all {
- tailf:cli-add-mode;
- tailf:cli-mode-name "config-xcvr-type";
- tailf:cli-full-command;
- // transceiver type all / monitoring
- container monitoring {
- tailf:info "Enable/disable monitoring";
- presence true;
- leaf interval {
- tailf:info "Set interval for monitoring";
- type uint16 {
- tailf:info "<300-3600>;;Time interval for monitoring "+
- "transceiver in seconds";
- range "300..3600";
- }
- }
- }
- }
- }
-}
-```
-
-
-
-tailf:cli-mode-name
-
-This annotation is not really needed when writing a NED. It is used to tell the CLI which prompt to use when in the submode. Without specific instructions, the CLI will invent a prompt based on the name of the submode container/list and the list instance. If a specific prompt is desired this annotation can be used. For example:
-
-```yang
-container transceiver {
- tailf:info "Select from transceiver configuration commands";
- container "type" {
- tailf:info "type keyword";
- // transceiver type all
- container all {
- tailf:cli-add-mode;
- tailf:cli-mode-name "config-xcvr-type";
- tailf:cli-full-command;
- // transceiver type all / monitoring
- container monitoring {
- tailf:info "Enable/disable monitoring";
- presence true;
- leaf interval {
- tailf:info "Set interval for monitoring";
- type uint16 {
- tailf:info "<300-3600>;;Time interval for monitoring "+
- "transceiver in seconds";
- range "300..3600";
- }
- }
- }
- }
- }
-}
-```
-
-
-
-
-
-This annotation is used to indicate that a leaf should accept multiple tokens, and concatenate them. By default, only a single token is accepted as value to a leaf. If spaces are required then the value needs to be quoted. If this isn't desired the `tailf:cli-multi-value` annotation can be used to tell the parser that a leaf should accept multiple tokens. A common example of this is the description command. It is modeled as:
-
-```
-// event manager applet * / description
-leaf "description" {
- tailf:info "Add or modify an applet description";
- tailf:cli-full-command;
- tailf:cli-multi-value;
- type string {
- tailf:info "LINE;;description";
- }
-}
-```
-
-In the above example, the description command will take all tokens to the end of the line, concatenate them with a space, and use that for leaf value. The `tailf:cli-full-command` annotation is used to tell the parser that no other command following this can be entered on the same command line. The parser would not be able to determine when the argument to this command ended and the next command commenced anyway.
-
-
-
-tailf:cli-multi-value
-
-This annotation is used to indicate that a leaf should accept multiple tokens, and concatenate them. By default, only a single token is accepted as value to a leaf. If spaces are required then the value needs to be quoted. If this isn't desired the `tailf:cli-multi-value` annotation can be used to tell the parser that a leaf should accept multiple tokens. A common example of this is the description command. It is modeled as:
-
-```
-// event manager applet * / description
-leaf "description" {
- tailf:info "Add or modify an applet description";
- tailf:cli-full-command;
- tailf:cli-multi-value;
- type string {
- tailf:info "LINE;;description";
- }
-}
-```
-
-In the above example, the description command will take all tokens to the end of the line, concatenate them with a space, and use that for leaf value. The `tailf:cli-full-command` annotation is used to tell the parser that no other command following this can be entered on the same command line. The parser would not be able to determine when the argument to this command ended and the next command commenced anyway.
-
-
-
-
-
-By default, all key values consist of a single parser token, i.e. a string without spaces, or a quoted string. If multiple tokens should be accepted for a single key element, without quotes, then the `tailf:cli-multi-word-key` annotation can be used. The sub-annotation `tailf:cli-max-words` can be used to tell the parser that at most a fixed number of words should be allowed for the key. For example:
-
-```yang
-container permit {
- tailf:info "Specify community to accept";
- presence "Specify community to accept";
- list permit-list {
- tailf:cli-suppress-mode;
- tailf:cli-delete-when-empty;
- tailf:cli-drop-node-name;
- key expr;
- leaf expr {
- tailf:cli-multi-word-key {
- tailf:cli-max-words 10;
- }
- type string {
- tailf:info "LINE;;An ordered list as a regular-expression";
- }
- }
- }
-}
-```
-
-The `tailf:cli-max-words` annotation can be used to allow more things to be entered on the same command line.
-
-
-
-tailf:cli-multi-word-key and tailf:cli-max-words
-
-By default, all key values consist of a single parser token, i.e. a string without spaces, or a quoted string. If multiple tokens should be accepted for a single key element, without quotes, then the `tailf:cli-multi-word-key` annotation can be used. The sub-annotation `tailf:cli-max-words` can be used to tell the parser that at most a fixed number of words should be allowed for the key. For example:
-
-```yang
-container permit {
- tailf:info "Specify community to accept";
- presence "Specify community to accept";
- list permit-list {
- tailf:cli-suppress-mode;
- tailf:cli-delete-when-empty;
- tailf:cli-drop-node-name;
- key expr;
- leaf expr {
- tailf:cli-multi-word-key {
- tailf:cli-max-words 10;
- }
- type string {
- tailf:info "LINE;;An ordered list as a regular-expression";
- }
- }
- }
-}
-```
-
-The `tailf:cli-max-words` annotation can be used to allow more things to be entered on the same command line.
-
-
-
-
-
-When generating delete commands towards the device, the default behavior is to simply add `no` in front of the line you are trying to remove. However, this is not always allowed. In some cases, only parts of the command are allowed. For example, suppose you have the data model:
-
-```yang
-container ospf {
- tailf:info "OSPF routes Administrative distance";
- leaf external {
- tailf:info "External routes";
- type uint32 {
- range "1.. 255";
- tailf:info "<1-255>;;Distance for external routes";
- }
- tailf:cli-suppress-no;
- tailf:cli-no-value-on-delete;
- tailf:cli-no-name-on-delete;
- }
- leaf inter-area {
- tailf:info "Inter-area routes";
- type uint32 {
- range "1.. 255";
- tailf:info "<1-255>;;Distance for inter-area routes";
- }
- tailf:cli-suppress-no;
- tailf:cli-no-name-on-delete;
- tailf:cli-no-value-on-delete;
- }
- leaf intra-area {
- tailf:info "Intra-area routes";
- type uint32 {
- range "1.. 255";
- tailf:info "<1-255>;;Distance for intra-area routes";
- }
- tailf:cli-suppress-no;
- tailf:cli-no-name-on-delete;
- tailf:cli-no-value-on-delete;
- }
-}
-```
-
-If the old configuration has the configuration `ospf external 3 inter-area 4 intra-area 1` then the default behavior would be to send `no ospf external 3 inter-area 4 intra-area 1` but this would generate an error. Instead, the device simply wants `no ospf`. This is then achieved by adding `tailf:cli-no-name-on-delete` (telling the CLI engine to remove the element name from the no line), and `tailf:cli-no-value-on-delete` (telling the CLI engine to strip the leaf value from the command line to be sent).
-
-
-
-tailf:cli-no-name-on-delete and tailf:cli-no-value-on-delete
-
-When generating delete commands towards the device, the default behavior is to simply add `no` in front of the line you are trying to remove. However, this is not always allowed. In some cases, only parts of the command are allowed. For example, suppose you have the data model:
-
-```yang
-container ospf {
- tailf:info "OSPF routes Administrative distance";
- leaf external {
- tailf:info "External routes";
- type uint32 {
- range "1.. 255";
- tailf:info "<1-255>;;Distance for external routes";
- }
- tailf:cli-suppress-no;
- tailf:cli-no-value-on-delete;
- tailf:cli-no-name-on-delete;
- }
- leaf inter-area {
- tailf:info "Inter-area routes";
- type uint32 {
- range "1.. 255";
- tailf:info "<1-255>;;Distance for inter-area routes";
- }
- tailf:cli-suppress-no;
- tailf:cli-no-name-on-delete;
- tailf:cli-no-value-on-delete;
- }
- leaf intra-area {
- tailf:info "Intra-area routes";
- type uint32 {
- range "1.. 255";
- tailf:info "<1-255>;;Distance for intra-area routes";
- }
- tailf:cli-suppress-no;
- tailf:cli-no-name-on-delete;
- tailf:cli-no-value-on-delete;
- }
-}
-```
-
-If the old configuration has the configuration `ospf external 3 inter-area 4 intra-area 1` then the default behavior would be to send `no ospf external 3 inter-area 4 intra-area 1` but this would generate an error. Instead, the device simply wants `no ospf`. This is then achieved by adding `tailf:cli-no-name-on-delete` (telling the CLI engine to remove the element name from the no line), and `tailf:cli-no-value-on-delete` (telling the CLI engine to strip the leaf value from the command line to be sent).
-
-
-
-
-
-This annotation is used in combination with `tailf:cli-sequence-commands`. It tells the parser that a leaf in the sequence isn't mandatory. Suppose you have the data model:
-
-```yang
-container foo {
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands;
- presence true;
- leaf a {
- tailf:cli-incomplete-command;
- type string;
- }
- leaf b {
- tailf:cli-incomplete-command;
- type string;
- }
- leaf c {
- type string;
- }
-}
-```
-
-If you want the command to behave as `foo a [b ] c `, it means that the leaves `a` and `c` are required and `b` is optional. If `b` is to be entered, it must be entered after `a` and before `c`. This would be achieved by adding `tailf:cli-optional-in-sequence` in `b`.
-
-```yang
-container foo {
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands;
- presence true;
- leaf a {
- tailf:cli-incomplete-command;
- type string;
- }
- leaf b {
- tailf:cli-incomplete-command;
- tailf:cli-optional-in-sequence;
- type string;
- }
- leaf c {
- type string;
- }
-}
-```
-
-A live example of this from the Cisco-ios data model is:
-
-```
-// voice translation-rule * / rule *
-list rule {
- tailf:info "Translation rule";
- tailf:cli-suppress-mode;
- tailf:cli-delete-when-empty;
- tailf:cli-incomplete-command;
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands {
- tailf:cli-reset-all-siblings;
- }
- ordered-by "user";
- key tag;
- leaf tag {
- type uint8 {
- tailf:info "<1-15>;;Translation rule tag";
- range "1..15";
- }
- }
- leaf reject {
- tailf:info "Call block rule";
- tailf:cli-optional-in-sequence;
- type empty;
- }
- leaf "pattern" {
- tailf:cli-drop-node-name;
- tailf:cli-full-command;
- tailf:cli-multi-value;
- type string {
- tailf:info "WORD;;Matching pattern";
- }
- }
-}
-```
-
-
-
-tailf:cli-optional-in-sequence
-
-This annotation is used in combination with `tailf:cli-sequence-commands`. It tells the parser that a leaf in the sequence isn't mandatory. Suppose you have the data model:
-
-```yang
-container foo {
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands;
- presence true;
- leaf a {
- tailf:cli-incomplete-command;
- type string;
- }
- leaf b {
- tailf:cli-incomplete-command;
- type string;
- }
- leaf c {
- type string;
- }
-}
-```
-
-If you want the command to behave as `foo a
-
-
-
-This annotation is used when the key element of a list isn't the first value that you give when setting a list element (for example when entering a submode). This is similar to `tailf:cli-hide-in-submode`, except it allows the leaf values to be entered in between key elements. In the example below the match leaf is entered before giving the filter ID.
-
-```yang
-container radius {
- tailf:info "RADIUS server configuration command";
- // radius filter *
- list filter {
- tailf:info "Packet filter configuration";
- key id;
- leaf id {
- type string {
- tailf:info "WORD;;Name of the filter (max 31 characters, longer will "
- +"be rejected";
- }
- }
- leaf match {
- tailf:cli-drop-node-name;
- tailf:cli-prefix-key;
- type enumeration {
- enum match-all {
- tailf:info "Filter if all of the attributes matches";
- }
- enum match-any {
- tailf:info "Filter if any of the attributes matches";
- }
- }
- }
-}
-```
-
-It is also possible to have a sub-annotation to `tailf:cli-prefix-key` that specifies that the leaf should occur before a certain key position. For example:
-
-```yang
-list route-map {
- tailf:info "Route map tag";
- tailf:cli-mode-name "config-route-map";
- tailf:cli-compact-syntax;
- tailf:cli-full-command;
- key "name sequence";
- leaf name {
- type string {
- tailf:info "WORD;;Route map tag";
- }
- }
- // route-map * #
- leaf sequence {
- tailf:cli-drop-node-name;
- type uint16 {
- tailf:info "<0-65535>;;Sequence to insert to/delete from "
- +"existing route-map entry";
- range "0..65535";
- }
- }
- // route-map * permit
- // route-map * deny
- leaf operation {
- tailf:cli-drop-node-name;
- tailf:cli-prefix-key {
- tailf:cli-before-key 2;
- }
- type enumeration {
- enum deny {
- tailf:code-name "op_deny";
- tailf:info "Route map denies set operations";
- }
- enum permit {
- tailf:code-name "op_internet";
- tailf:info "Route map permits set operations";
- }
- }
- default permit;
- }
- // route-map * / description
- leaf "description" {
- tailf:info "Route-map comment";
- tailf:cli-multi-value;
- type string {
- tailf:info "LINE;;Comment up to 100 characters";
- length "0..100";
- }
- }
-}
-```
-
-The keys for this list are `name` and `sequence`, but in between you need to specify `deny` or `permit`. This is not a key since you cannot have two different list instances with the same name and sequence number, but differ in `deny` and `permit`.
-
-
-
-tailf:cli-prefix-key
-
-This annotation is used when the key element of a list isn't the first value that you give when setting a list element (for example when entering a submode). This is similar to `tailf:cli-hide-in-submode`, except it allows the leaf values to be entered in between key elements. In the example below the match leaf is entered before giving the filter ID.
-
-```yang
-container radius {
- tailf:info "RADIUS server configuration command";
- // radius filter *
- list filter {
- tailf:info "Packet filter configuration";
- key id;
- leaf id {
- type string {
- tailf:info "WORD;;Name of the filter (max 31 characters, longer will "
- +"be rejected";
- }
- }
- leaf match {
- tailf:cli-drop-node-name;
- tailf:cli-prefix-key;
- type enumeration {
- enum match-all {
- tailf:info "Filter if all of the attributes matches";
- }
- enum match-any {
- tailf:info "Filter if any of the attributes matches";
- }
- }
- }
-}
-```
-
-It is also possible to have a sub-annotation to `tailf:cli-prefix-key` that specifies that the leaf should occur before a certain key position. For example:
-
-```yang
-list route-map {
- tailf:info "Route map tag";
- tailf:cli-mode-name "config-route-map";
- tailf:cli-compact-syntax;
- tailf:cli-full-command;
- key "name sequence";
- leaf name {
- type string {
- tailf:info "WORD;;Route map tag";
- }
- }
- // route-map * #
- leaf sequence {
- tailf:cli-drop-node-name;
- type uint16 {
- tailf:info "<0-65535>;;Sequence to insert to/delete from "
- +"existing route-map entry";
- range "0..65535";
- }
- }
- // route-map * permit
- // route-map * deny
- leaf operation {
- tailf:cli-drop-node-name;
- tailf:cli-prefix-key {
- tailf:cli-before-key 2;
- }
- type enumeration {
- enum deny {
- tailf:code-name "op_deny";
- tailf:info "Route map denies set operations";
- }
- enum permit {
- tailf:code-name "op_internet";
- tailf:info "Route map permits set operations";
- }
- }
- default permit;
- }
- // route-map * / description
- leaf "description" {
- tailf:info "Route-map comment";
- tailf:cli-multi-value;
- type string {
- tailf:info "LINE;;Comment up to 100 characters";
- length "0..100";
- }
- }
-}
-```
-
-The keys for this list are `name` and `sequence`, but in between you need to specify `deny` or `permit`. This is not a key since you cannot have two different list instances with the same name and sequence number, but differ in `deny` and `permit`.
-
-
-
-
-
-This annotation is used to group together list instances, or values in a leaf-list into ranges. The type of the value is not restricted to integers only. It works with a string also, and it is possible to have a value like this: 1-5, t1, t2.
-
-```
-// spanning-tree vlans-root
-container vlans-root {
- tailf:cli-drop-node-name;
- list vlan {
- tailf:info "VLAN Switch Spanning Tree";
- tailf:cli-range-list-syntax;
- tailf:cli-suppress-mode;
- tailf:cli-delete-when-empty;
- key id;
- leaf id {
- type uint16 {
- tailf:info "WORD;;vlan range, example: 1,3-5,7,9-11";
- range "1..4096";
- }
- }
- }
-}
-```
-
-What will exist in the database is separate instances, i.e. if the configuration is `vlan 1,3-5,7,9-11` this will result in the database having the instances 1,3,4,5,7,9,10, and 11. Similarly, to create these instances on the device, the command generated by NSO will be `vlan 1,3-5,7,9-11`. Without this annotation, NSO would generate unique commands for each instance, i.e.:
-
-```
-vlan 1
-vlan 2
-vlan 3
-vlan 5
-vlan 7
-...
-```
-
-Same thing for leaf-lists:
-
-```
-leaf-list vlan {
- tailf:info "Range of vlans to add to the instance mapping";
- tailf:cli-range-list-syntax;
- type uint16 {
- tailf:info "LINE;;vlan range ex: 1-65, 72, 300 -200";
- }
-}
-```
-
-
-
-tailf:cli-range-list-syntax
-
-This annotation is used to group together list instances, or values in a leaf-list into ranges. The type of the value is not restricted to integers only. It works with a string also, and it is possible to have a value like this: 1-5, t1, t2.
-
-```
-// spanning-tree vlans-root
-container vlans-root {
- tailf:cli-drop-node-name;
- list vlan {
- tailf:info "VLAN Switch Spanning Tree";
- tailf:cli-range-list-syntax;
- tailf:cli-suppress-mode;
- tailf:cli-delete-when-empty;
- key id;
- leaf id {
- type uint16 {
- tailf:info "WORD;;vlan range, example: 1,3-5,7,9-11";
- range "1..4096";
- }
- }
- }
-}
-```
-
-What will exist in the database is separate instances, i.e. if the configuration is `vlan 1,3-5,7,9-11` this will result in the database having the instances 1,3,4,5,7,9,10, and 11. Similarly, to create these instances on the device, the command generated by NSO will be `vlan 1,3-5,7,9-11`. Without this annotation, NSO would generate unique commands for each instance, i.e.:
-
-```
-vlan 1
-vlan 2
-vlan 3
-vlan 5
-vlan 7
-...
-```
-
-Same thing for leaf-lists:
-
-```
-leaf-list vlan {
- tailf:info "Range of vlans to add to the instance mapping";
- tailf:cli-range-list-syntax;
- type uint16 {
- tailf:info "LINE;;vlan range ex: 1-65, 72, 300 -200";
- }
-}
-```
-
-
-
-
-
-Some settings need to be unset before they can be set. This can be accommodated by using the `tailf:cli-remove-before-change` annotation. An example of such a leaf is:
-
-```
-// ip vrf * / rd
-leaf rd {
- tailf:info "Specify Route Distinguisher";
- tailf:cli-full-command;
- tailf:cli-remove-before-change;
- type rd-type;
-}
-```
-
-You are not allowed to define a new route distinguisher before removing the old one.
-
-
-
-tailf:cli-remove-before-change
-
-Some settings need to be unset before they can be set. This can be accommodated by using the `tailf:cli-remove-before-change` annotation. An example of such a leaf is:
-
-```
-// ip vrf * / rd
-leaf rd {
- tailf:info "Specify Route Distinguisher";
- tailf:cli-full-command;
- tailf:cli-remove-before-change;
- type rd-type;
-}
-```
-
-You are not allowed to define a new route distinguisher before removing the old one.
-
-
-
-
-
-This annotation is used on leaf-lists to tell the CLI engine that the entire list should be written and not just the additions or subtractions, which is the default behavior for leaf-lists. For example:
-
-```
-// controller * / channel-group
-list channel-group {
- tailf:info "Specify the timeslots to channel-group "+
- "mapping for an interface";
- tailf:cli-suppress-mode;
- tailf:cli-delete-when-empty;
- key number;
- leaf number {
- type uint8 {
- range "0..30";
- }
- }
- leaf-list timeslots {
- tailf:cli-replace-all;
- tailf:cli-range-list-syntax;
- type uint16;
- }
-}
-```
-
-The `timeslots` leaf is changed by writing the entire range value. The default would be to generate commands for adding and deleting values from the range.
-
-
-
-tailf:cli-replace-all
-
-This annotation is used on leaf-lists to tell the CLI engine that the entire list should be written and not just the additions or subtractions, which is the default behavior for leaf-lists. For example:
-
-```
-// controller * / channel-group
-list channel-group {
- tailf:info "Specify the timeslots to channel-group "+
- "mapping for an interface";
- tailf:cli-suppress-mode;
- tailf:cli-delete-when-empty;
- key number;
- leaf number {
- type uint8 {
- range "0..30";
- }
- }
- leaf-list timeslots {
- tailf:cli-replace-all;
- tailf:cli-range-list-syntax;
- type uint16;
- }
-}
-```
-
-The `timeslots` leaf is changed by writing the entire range value. The default would be to generate commands for adding and deleting values from the range.
-
-
-
-
-
-This annotation is a sub-annotation to `tailf:cli-sequence-commands`. The problem it addresses is what should happen when a command that takes multiple parameters is run a second time. Consider the data model:
-
-```yang
-container foo {
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands {
- tailf:cli-reset-siblings;
- }
- presence true;
- leaf a {
- type string;
- }
- leaf b {
- type string;
- }
- leaf c {
- type string;
- }
-}
-```
-
-You are allowed to enter any of the below commands:
-
-```
-foo
-foo a
-foo a b
-foo a b c
-```
-
-If you first enter the command `foo a 1 b 2 c 3`, what will be stored in the database is foo being present, the leaf `a` having the value 1, the leaf b having the value 2, and the leaf `c` having the value 3.
-
-Now, if the command `foo a 3` is executed, it will set the value of leaf `a` to 3, but will leave leaf `b` and `c` as they were before. This is probably not the way the device works. In most cases, it expects the leaves `b` and `c` to be unset. The annotation `tailf:cli-reset-siblings` tells the CLI engine that all siblings covered by the `tailf:cli-sequence-commands` should be reset.
-
-Another similar case is when you have some leaves covered by the command sequencing, and some not. For example:
-
-```yang
-container foo {
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands {
- tailf:cli-reset-all-siblings;
- }
- presence true;
- leaf a {
- type string;
- }
- leaf b {
- tailf:cli-break-sequence-commands;
- type string;
- }
- leaf c {
- type string;
- }
-}
-```
-
-The above model will allow the user to enter the b and c leaves in any order, as long as leaf a is entered first. The annotation `tailf:cli-reset-siblings` will reset the leaves up to the `tailf:cli-break-sequence-commands`. The `tailf:cli-reset-all-siblings` tells the CLI engine to reset all siblings, also those outside the command sequencing.
-
-
-
-tailf:cli-reset-siblings and tailf:cli-reset-all-siblings
-
-This annotation is a sub-annotation to `tailf:cli-sequence-commands`. The problem it addresses is what should happen when a command that takes multiple parameters is run a second time. Consider the data model:
-
-```yang
-container foo {
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands {
- tailf:cli-reset-siblings;
- }
- presence true;
- leaf a {
- type string;
- }
- leaf b {
- type string;
- }
- leaf c {
- type string;
- }
-}
-```
-
-You are allowed to enter any of the below commands:
-
-```
-foo
-foo a
-
-
-
-This annotation can be used on both containers/lists and on leaves, but has slightly different meaning. When used on a container it means that whenever the container is entered, all leaves in it are reset.
-
-If used on a leaf, it should be understood as whenever that leaf is set all other leaves in the container are reset. For example:
-
-```
-// license udi
-container udi {
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands;
- tailf:cli-reset-container;
- leaf pid {
- type string;
- }
- leaf sn {
- type string;
- }
-}
-container ietf {
- tailf:info "IETF graceful restart";
- container helper {
- tailf:info "helper support";
- presence "helper support";
- leaf disable {
- tailf:cli-reset-container;
- tailf:cli-delete-container-on-delete;
- tailf:info "disable helper support";
- type empty;
- }
- leaf strict-lsa-checking {
- tailf:info "enable helper strict LSA checking";
- type empty;
- }
-}
-```
-
-
-
-tailf:cli-reset-container
-
-This annotation can be used on both containers/lists and on leaves, but has slightly different meaning. When used on a container it means that whenever the container is entered, all leaves in it are reset.
-
-If used on a leaf, it should be understood as whenever that leaf is set all other leaves in the container are reset. For example:
-
-```
-// license udi
-container udi {
- tailf:cli-compact-syntax;
- tailf:cli-sequence-commands;
- tailf:cli-reset-container;
- leaf pid {
- type string;
- }
- leaf sn {
- type string;
- }
-}
-container ietf {
- tailf:info "IETF graceful restart";
- container helper {
- tailf:info "helper support";
- presence "helper support";
- leaf disable {
- tailf:cli-reset-container;
- tailf:cli-delete-container-on-delete;
- tailf:info "disable helper support";
- type empty;
- }
- leaf strict-lsa-checking {
- tailf:info "enable helper strict LSA checking";
- type empty;
- }
-}
-```
-
-
-
-
-
-Changes to lists that have the `ordered-by "user"` annotation are shown as insert, delete, and move operations. However, most devices do not support such operations on the lists. In these cases, if you want to insert an element in the middle of a list, you need to first delete all elements following the insertion point, add the new element, and then add all the elements you deleted. The `tailf:cli-show-long-obu-diffs` tells the CLI engine to do exactly this. For example:
-
-```yang
-list foo {
- ordered-by user;
- tailf:cli-show-long-obu-diffs;
- tailf:cli-suppress-mode;
- key id;
- leaf id {
- type string;
- }
-}
-```
-
-If the old configuration is:
-
-```
-foo a
-foo b
-foo c
-foo d
-```
-
-The desired configuration is:
-
-```
-foo a
-foo b
-foo e
-foo c
-foo d
-```
-
-NSO will send the following to the device:
-
-```
-no foo c
-no foo d
-foo e
-foo c
-foo d
-```
-
-An example from the cisco-ios model is:
-
-```
-// ip access-list extended *
-container extended {
- tailf:info "Extended Access List";
- tailf:cli-incomplete-command;
- list ext-named-acl {
- tailf:cli-drop-node-name;
- tailf:cli-full-command;
- tailf:cli-mode-name "config-ext-nacl";
- key name;
- leaf name {
- type ext-acl-type;
- }
- list ext-access-list-rule {
- tailf:cli-suppress-mode;
- tailf:cli-delete-when-empty;
- tailf:cli-drop-node-name;
- tailf:cli-compact-syntax;
- tailf:cli-show-long-obu-diffs;
- ordered-by user;
- key rule;
- leaf rule {
- tailf:cli-drop-node-name;
- tailf:cli-multi-word-key;
- type string {
- tailf:info "deny;;Specify packets to reject\n"+
- "permit;;Specify packets to forwards\n"+
- "remark;;Access list entry comment";
- pattern "(permit.*)|(deny.*)|(no.*)|(remark.*)|([0-9]+.*)";
- }
- }
- }
- }
-}
-```
-
-
-
-tailf:cli-show-long-obu-diffs
-
-Changes to lists that have the `ordered-by "user"` annotation are shown as insert, delete, and move operations. However, most devices do not support such operations on the lists. In these cases, if you want to insert an element in the middle of a list, you need to first delete all elements following the insertion point, add the new element, and then add all the elements you deleted. The `tailf:cli-show-long-obu-diffs` tells the CLI engine to do exactly this. For example:
-
-```yang
-list foo {
- ordered-by user;
- tailf:cli-show-long-obu-diffs;
- tailf:cli-suppress-mode;
- key id;
- leaf id {
- type string;
- }
-}
-```
-
-If the old configuration is:
-
-```
-foo a
-foo b
-foo c
-foo d
-```
-
-The desired configuration is:
-
-```
-foo a
-foo b
-foo e
-foo c
-foo d
-```
-
-NSO will send the following to the device:
-
-```
-no foo c
-no foo d
-foo e
-foo c
-foo d
-```
-
-An example from the cisco-ios model is:
-
-```
-// ip access-list extended *
-container extended {
- tailf:info "Extended Access List";
- tailf:cli-incomplete-command;
- list ext-named-acl {
- tailf:cli-drop-node-name;
- tailf:cli-full-command;
- tailf:cli-mode-name "config-ext-nacl";
- key name;
- leaf name {
- type ext-acl-type;
- }
- list ext-access-list-rule {
- tailf:cli-suppress-mode;
- tailf:cli-delete-when-empty;
- tailf:cli-drop-node-name;
- tailf:cli-compact-syntax;
- tailf:cli-show-long-obu-diffs;
- ordered-by user;
- key rule;
- leaf rule {
- tailf:cli-drop-node-name;
- tailf:cli-multi-word-key;
- type string {
- tailf:info "deny;;Specify packets to reject\n"+
- "permit;;Specify packets to forwards\n"+
- "remark;;Access list entry comment";
- pattern "(permit.*)|(deny.*)|(no.*)|(remark.*)|([0-9]+.*)";
- }
- }
- }
- }
-}
-```
-
-
-
-
-
-One common CLI behavior is to not only show when something is configured but also when it isn't configured by displaying it as `no `. You can tell the CLI engine that you want this behavior by using the `tailf:cli-show-no` annotation. It can be used both on leaves and on presence containers. For example:
-
-```
-// ipv6 cef
-container cef {
- tailf:info "Cisco Express Forwarding";
- tailf:cli-display-separated;
- tailf:cli-show-no;
- presence true;
-}
-```
-
-And,
-
-```
-// interface * / shutdown
-leaf shutdown {
- // Note: default to "no shutdown" in order to be able to bring if up.
- tailf:info "Shutdown the selected interface";
- tailf:cli-full-command;
- tailf:cli-show-no;
- type empty;
-}
-```
-
-However, this is a much more subtle behaviour than one may think and it is not obvious when the `tailf:cli-show-no` and the `tailf:cli-boolean-no` should be used. For example, it would also be possible to model the `shutdown` leaf a boolean value, i.e.:
-
-```
-// interface * / shutdown
-leaf shutdown {
- tailf:cli-boolean-no;
- type boolean;
-}
-```
-
-The problem with the above is that when a new interface is created, say a VLAN interface, the `shutdown` leaf would not be set to anything and you would not send anything to the device. With the `cli-show-no` definition, you would send `no shutdown` since the shutdown leaf would not be defined when a new interface VLAN instance is created.
-
-The boolean version can be tweaked to behave in a similar way using the `default` annotation and `tailf:cli-show-with-default`, i.e.:
-
-```
-// interface * / shutdown
-leaf shutdown {
- tailf:cli-show-with-default;
- tailf:cli-boolean-no;
- type boolean;
- default "false";
-}
-```
-
-The problem with this is that if you explicitly configure the leaf to false in NSO, you will send `no shutdown` to the device (which is fine), but if you then read the config from the device it will not display `no shutdown` since it now has its default setting. This will lead to an out-of-sync situation in NSO. NSO thinks the value should be set to false (which is different from the leaf not being set), whereas the device reports the value as being unset.
-
-The whole situation comes from the fact that NSO and the device treat default values differently. NSO considers a leaf as either being set or not set. If a leaf is set to its default value, it is still considered as set. A leaf must be explicitly deleted for it to become unset. Whereas a typical Cisco device considers a leaf unset if you set it to its default value.
-
-
-
-tailf:cli-show-no
-
-One common CLI behavior is to not only show when something is configured but also when it isn't configured by displaying it as `no
-
-
-
-This tells the CLI engine to render a leaf not only when it is actually set, but also when it has its default value. For example:
-
-```yang
-leaf "input" {
- tailf:cli-boolean-no;
- tailf:cli-show-with-default;
- tailf:cli-full-command;
- type boolean;
- default true;
-}
-```
-
-
-
-tailf:cli-show-with-default
-
-This tells the CLI engine to render a leaf not only when it is actually set, but also when it has its default value. For example:
-
-```yang
-leaf "input" {
- tailf:cli-boolean-no;
- tailf:cli-show-with-default;
- tailf:cli-full-command;
- type boolean;
- default true;
-}
-```
-
-
-
-
-
-Tells the CLI that it should not be possible to delete all lists instances, i.e. the command `no foo` is not allowed, it needs to be `no foo `. For example:
-
-```yang
-list class-map {
- tailf:info "Configure QoS Class Map";
- tailf:cli-mode-name "config-cmap";
- tailf:cli-suppress-list-no;
- tailf:cli-delete-when-empty;
- tailf:cli-no-key-completion;
- tailf:cli-sequence-commands;
- tailf:cli-full-command;
- // class-map *
- key name;
- leaf name {
- tailf:cli-disallow-value "type|match-any|match-all";
- type string {
- tailf:info "WORD;;class-map name";
- }
- }
-}
-```
-
-
-
-tailf:cli-suppress-list-no
-
-Tells the CLI that it should not be possible to delete all lists instances, i.e. the command `no foo` is not allowed, it needs to be `no foo
-
-
-
-By default, all lists are rendered as submodes. This can be suppressed using the `tailf:cli-suppress-mode` annotation. For example, the data model:
-
-```yang
-list foo {
- key id;
- leaf id {
- type string;
- }
- leaf mtu {
- type uint16;
- }
-}
-```
-
-If you have the configuration:
-
-```
-foo a {
- mtu 1400;
-}
-foo b {
- mtu 1500;
-}
-```
-
-It would be rendered as:
-
-```
-foo a
-mtu 1400
-!
-foo b
-mtu 1500
-!
-```
-
-However, if you add `tailf:cli-suppress-mode`:
-
-```yang
-list foo {
- tailf:cli-suppress-mode;
- key id;
- leaf id {
- type string;
- }
- leaf mtu {
- type uint16;
- }
-}
-```
-
-It will be rendered as:
-
-```
-foo a mtu 1400
-foo b mtu 1500
-```
-
-
-
-tailf:cli-suppress-mode
-
-By default, all lists are rendered as submodes. This can be suppressed using the `tailf:cli-suppress-mode` annotation. For example, the data model:
-
-```yang
-list foo {
- key id;
- leaf id {
- type string;
- }
- leaf mtu {
- type uint16;
- }
-}
-```
-
-If you have the configuration:
-
-```
-foo a {
- mtu 1400;
-}
-foo b {
- mtu 1500;
-}
-```
-
-It would be rendered as:
-
-```
-foo a
-mtu 1400
-!
-foo b
-mtu 1500
-!
-```
-
-However, if you add `tailf:cli-suppress-mode`:
-
-```yang
-list foo {
- tailf:cli-suppress-mode;
- key id;
- leaf id {
- type string;
- }
- leaf mtu {
- type uint16;
- }
-}
-```
-
-It will be rendered as:
-
-```
-foo a mtu 1400
-foo b mtu 1500
-```
-
-
-
-
-
-The format string is used when parsing a key value and when generating a key value for an existing configuration. The key items are numbered from 1-N and the format string should indicate how they are related by using $(X) (where X is the key number). For example:
-
-```yang
-list interface {
- tailf:cli-key-format "$(1)/$(2)/$(3):$(4)";
- key "chassis slot subslot number";
- leaf chassis {
- type uint8 {
- range "1 .. 4";
- }
- }
- leaf slot {
- type uint8 {
- range "1 .. 16";
- }
- }
- leaf subslot {
- type uint8 {
- range "1 .. 48";
- }
- }
- leaf number {
- type uint8 {
- range "1 .. 255";
- }
- }
-}
-```
-
-It will be rendered as:
-
-```
-interface 1/2/3:4
-```
-
-
-
-tailf:cli-key-format
-
-The format string is used when parsing a key value and when generating a key value for an existing configuration. The key items are numbered from 1-N and the format string should indicate how they are related by using $(X) (where X is the key number). For example:
-
-```yang
-list interface {
- tailf:cli-key-format "$(1)/$(2)/$(3):$(4)";
- key "chassis slot subslot number";
- leaf chassis {
- type uint8 {
- range "1 .. 4";
- }
- }
- leaf slot {
- type uint8 {
- range "1 .. 16";
- }
- }
- leaf subslot {
- type uint8 {
- range "1 .. 48";
- }
- }
- leaf number {
- type uint8 {
- range "1 .. 255";
- }
- }
-}
-```
-
-It will be rendered as:
-
-```
-interface 1/2/3:4
-```
-
-
-
-
-
-When generating configuration diffs delete all contents of a container or list before deleting the node. For example:
-
-```yang
-list foo {
- tailf:cli-recursive-delete;
- key "id"";
- leaf id {
- type string;
- }
- leaf a {
- type uint8;
- }
- leaf b {
- type uint8;
- }
- leaf c {
- type uint8;
- }
-}
-```
-
-It will be rendered as:
-
-```bash
-# show full
-foo bar
- a 1
- b 2
- c 3
-!
-# ex
-# no foo bar
-# show configuration
-foo bar
- no a 1
- no b 2
- no c 3
-!
-no foo bar
-#
-```
-
-
-
-tailf:cli-recursive-delete
-
-When generating configuration diffs delete all contents of a container or list before deleting the node. For example:
-
-```yang
-list foo {
- tailf:cli-recursive-delete;
- key "id"";
- leaf id {
- type string;
- }
- leaf a {
- type uint8;
- }
- leaf b {
- type uint8;
- }
- leaf c {
- type uint8;
- }
-}
-```
-
-It will be rendered as:
-
-```bash
-# show full
-foo bar
- a 1
- b 2
- c 3
-!
-# ex
-# no foo bar
-# show configuration
-foo bar
- no a 1
- no b 2
- no c 3
-!
-no foo bar
-#
-```
-
-
-
-
-
-Specifies that the CLI should not auto-render `no` commands for this element. An element with this annotation will not appear in the completion list to the `no` command. For example:
-
-```yang
-list foo {
- tailf:cli-recursive-delete;
- key "id"";
- leaf id {
- type string;
- }
- leaf a {
- type uint8;
- }
- leaf b {
- tailf:cli-suppress-no;
- type uint8;
- }
- leaf c {
- type uint8;
- }
-}
-```
-
-It will be rendered as:
-
-```
-(config-foo-bar)# no ?
-Possible completions:
- a
- c
- ---
-```
-
-The problem with the above is that the diff will still generate the **no**. To avoid it, you must use the `tailf:cli-no-value-on-delete` and `tailf:cli-no-name-on-delete`.
-
-```
-(config-foo-bar)# no ?
-Possible completions:
- a
- c
- ---
- service Modify use of network based services
-(config-foo-bar)# ex
-(config)# no foo bar
-(config)# show config
-foo bar
- no a 1
- no b 2
- no c 3
-!
-no foo bar
-(config)#
-```
-
-
-
-tailf:cli-suppress-no
-
-Specifies that the CLI should not auto-render `no` commands for this element. An element with this annotation will not appear in the completion list to the `no` command. For example:
-
-```yang
-list foo {
- tailf:cli-recursive-delete;
- key "id"";
- leaf id {
- type string;
- }
- leaf a {
- type uint8;
- }
- leaf b {
- tailf:cli-suppress-no;
- type uint8;
- }
- leaf c {
- type uint8;
- }
-}
-```
-
-It will be rendered as:
-
-```
-(config-foo-bar)# no ?
-Possible completions:
- a
- c
- ---
-```
-
-The problem with the above is that the diff will still generate the **no**. To avoid it, you must use the `tailf:cli-no-value-on-delete` and `tailf:cli-no-name-on-delete`.
-
-```
-(config-foo-bar)# no ?
-Possible completions:
- a
- c
- ---
- service Modify use of network based services
-(config-foo-bar)# ex
-(config)# no foo bar
-(config)# show config
-foo bar
- no a 1
- no b 2
- no c 3
-!
-no foo bar
-(config)#
-```
-
-
-
-
-
-Do not display the value if it is the same as default. Please note that this annotation works only in the case of with-defaults basic-mode capability set to `explicit` and the value is explicitly set by the user to the default value. For example:
-
-```yang
-list foo {
- key "id"";
- leaf id {
- type string;
- }
- leaf a {
- type uint8;
- default 1;
- }
- leaf b {
- tailf:cli-trim-default;
- type uint8;
- default 2;
- }
-}
-```
-
-It will be rendered as:
-
-```
-(config)# foo bar
-(config-foo-bar)# a ?
-Possible completions:
- [1]
-(config-foo-bar)# a 2 b ?
-Possible completions:
- [2]
-(config-foo-bar)# a 2 b 3
-(config-foo-bar)# commit
-Commit complete.
-(config-foo-bar)# show full
-foo bar
- a 2
- b 3
-!
-(config-foo-bar)# a 1 b 2
-(config-foo-bar)# commit
-Commit complete.
-(config-foo-bar)# show full
-foo bar
- a 1
-!
-```
-
-
-
-tailf:cli-trim-default
-
-Do not display the value if it is the same as default. Please note that this annotation works only in the case of with-defaults basic-mode capability set to `explicit` and the value is explicitly set by the user to the default value. For example:
-
-```yang
-list foo {
- key "id"";
- leaf id {
- type string;
- }
- leaf a {
- type uint8;
- default 1;
- }
- leaf b {
- tailf:cli-trim-default;
- type uint8;
- default 2;
- }
-}
-```
-
-It will be rendered as:
-
-```
-(config)# foo bar
-(config-foo-bar)# a ?
-Possible completions:
-
-
-
-
-Embed `no` in front of the element name instead of at the beginning of the line. For example:
-
-```yang
-list foo {
- key "id";
- leaf id {
- type string;
- }
- leaf a {
- type uint8;
- }
- container x {
- leaf b {
- type uint8;
- tailf:cli-embed-no-on-delete;
- }
- }
-}
-```
-
-It will be rendered as:
-
-```
-(config-foo-bar)# show full
-foo bar
- a 1
- x b 3
-!
-(config-foo-bar)# no x
-(config-foo-bar)# show conf
-foo bar
- x no b 3
-!
-```
-
-
-
-tailf:cli-embed-no-on-delete
-
-Embed `no` in front of the element name instead of at the beginning of the line. For example:
-
-```yang
-list foo {
- key "id";
- leaf id {
- type string;
- }
- leaf a {
- type uint8;
- }
- container x {
- leaf b {
- type uint8;
- tailf:cli-embed-no-on-delete;
- }
- }
-}
-```
-
-It will be rendered as:
-
-```
-(config-foo-bar)# show full
-foo bar
- a 1
- x b 3
-!
-(config-foo-bar)# no x
-(config-foo-bar)# show conf
-foo bar
- x no b 3
-!
-```
-
-
-
-
-
-This means that the non-integer key should allow range expressions. Can be used in key leafs only. The key must support a range format. The range applies only for matching existing instances. For example:
-
-```yang
-list interface {
- key name;
- leaf name {
- type string;
- tailf:cli-allow-range;
- }
- leaf number {
- type uint32;
- }
-}
-```
-
-It will be rendered as:
-
-```
-(config)# interface eth0-100 number 90
-Error: no matching instances found
-(config)# interface
-Possible completions:
- eth0 eth1 eth2 eth3 eth4 eth5 range
-(config)# interface eth0-3 number 100
-(config-interface-eth0-3)# ex
-(config)# interface eth4-5 number 200
-(config-interface-eth4-5)# commit
-Commit complete.
-(config-interface-eth4-5)# ex
-(config)# do show running-config interface
-interface eth0
- number 100
-!
-interface eth1
- number 100
-!
-interface eth2
- number 100
-!
-interface eth3
- number 100
-!
-interface eth4
- number 200
-!
-interface eth5
- number 200
-!
-```
-
-
-
-tailf:cli-allow-range
-
-This means that the non-integer key should allow range expressions. Can be used in key leafs only. The key must support a range format. The range applies only for matching existing instances. For example:
-
-```yang
-list interface {
- key name;
- leaf name {
- type string;
- tailf:cli-allow-range;
- }
- leaf number {
- type uint32;
- }
-}
-```
-
-It will be rendered as:
-
-```
-(config)# interface eth0-100 number 90
-Error: no matching instances found
-(config)# interface
-Possible completions:
-
-
-
-
-Specifies that this node is case-sensitive. If applied to a container or a list, any nodes below will also be case-sensitive. For example:
-
-```yang
-list foo {
- tailf:cli-case-sensitive;
- key "id";
- leaf id {
- type string;
- }
- leaf a {
- type string;
- }
-}
-```
-
-It will be rendered as:
-
-```
-(config)# foo bar a test
-(config-foo-bar)# ex
-(config)# commit
-Commit complete.
-(config)# do show running-config foo
-foo bar
- a test
-!
-(config)# foo bar a Test
-(config-foo-bar)# ex
-(config)# foo Bar a TEST
-(config-foo-Bar)# commit
-Commit complete.
-(config-foo-Bar)# ex
-(config)# do show running-config foo
-foo Bar
- a TEST
-!
-foo bar
- a Test
-!
-```
-
-
-
-tailf:cli-case-sensitive
-
-Specifies that this node is case-sensitive. If applied to a container or a list, any nodes below will also be case-sensitive. For example:
-
-```yang
-list foo {
- tailf:cli-case-sensitive;
- key "id";
- leaf id {
- type string;
- }
- leaf a {
- type string;
- }
-}
-```
-
-It will be rendered as:
-
-```
-(config)# foo bar a test
-(config-foo-bar)# ex
-(config)# commit
-Commit complete.
-(config)# do show running-config foo
-foo bar
- a test
-!
-(config)# foo bar a Test
-(config-foo-bar)# ex
-(config)# foo Bar a TEST
-(config-foo-Bar)# commit
-Commit complete.
-(config-foo-Bar)# ex
-(config)# do show running-config foo
-foo Bar
- a TEST
-!
-foo bar
- a Test
-!
-```
-
-
-
-
-
-When used force the CLI to display the namespace prefix of all children. For example:
-
-```yang
-list foo {
- tailf:cli-expose-ns-prefix;
- key "id"";
- leaf id {
- type string;
- }
- leaf a {
- type uint8;
- }
- leaf b {
- type uint8;
- }
- leaf c {
- type uint8;
- }
-}
-```
-
-It will be rendered as:
-
-```
-(config)# foo bar
-(config-foo-bar)# ?
-Possible completions:
- example:a
- example:b
- example:c
- ---
-```
-
-
-
-tailf:cli-expose-ns-prefix
-
-When used force the CLI to display the namespace prefix of all children. For example:
-
-```yang
-list foo {
- tailf:cli-expose-ns-prefix;
- key "id"";
- leaf id {
- type string;
- }
- leaf a {
- type uint8;
- }
- leaf b {
- type uint8;
- }
- leaf c {
- type uint8;
- }
-}
-```
-
-It will be rendered as:
-
-```
-(config)# foo bar
-(config-foo-bar)# ?
-Possible completions:
- example:a
- example:b
- example:c
- ---
-```
-
-
-
-
-
-Enforces the CLI engine to generate `insert` comments when displaying configuration changes of `ordered-by user` lists. Should not be used together with `tailf:cli-show-long-obu-diffs`. For example:
-
-```yang
- container policy {
- list policy-list {
- tailf:cli-drop-node-name;
- tailf:cli-show-obu-comments;
- ordered-by user;
- key policyid;
- leaf policyid {
- type uint32 {
- tailf:info "policyid;;Policy ID.";
- }
- }
- leaf-list srcintf {
- tailf:cli-flat-list-syntax {
- tailf:cli-replace-all;
- }
- type string;
- }
- leaf-list srcaddr {
- tailf:cli-flat-list-syntax {
- tailf:cli-replace-all;
- }
- type string;
- }
- leaf-list dstaddr {
- tailf:cli-flat-list-syntax {
- tailf:cli-replace-all;
- }
- type string;
- }
- leaf action {
- type enumeration {
- enum accept {
- tailf:info "Action accept.";
- }
- enum deny {
- tailf:info "Action deny.";
- }
- }
-```
-
-It will be rendered as:
-
-```cli
-admin@ncs(config-policy-4)# commit dry-run outformat cli
-...
- policy {
- policy-list 1 {
- - action accept;
- + action deny;
- }
- + # after policy-list 3
- + policy-list 4 {
- + srcintf aaa;
- + srcaddr bbb;
- + dstaddr ccc;
- + }
- }
- }
- }
- }
- }
-```
-
-
-
-tailf:cli-show-obu-comments
-
-Enforces the CLI engine to generate `insert` comments when displaying configuration changes of `ordered-by user` lists. Should not be used together with `tailf:cli-show-long-obu-diffs`. For example:
-
-```yang
- container policy {
- list policy-list {
- tailf:cli-drop-node-name;
- tailf:cli-show-obu-comments;
- ordered-by user;
- key policyid;
- leaf policyid {
- type uint32 {
- tailf:info "policyid;;Policy ID.";
- }
- }
- leaf-list srcintf {
- tailf:cli-flat-list-syntax {
- tailf:cli-replace-all;
- }
- type string;
- }
- leaf-list srcaddr {
- tailf:cli-flat-list-syntax {
- tailf:cli-replace-all;
- }
- type string;
- }
- leaf-list dstaddr {
- tailf:cli-flat-list-syntax {
- tailf:cli-replace-all;
- }
- type string;
- }
- leaf action {
- type enumeration {
- enum accept {
- tailf:info "Action accept.";
- }
- enum deny {
- tailf:info "Action deny.";
- }
- }
-```
-
-It will be rendered as:
-
-```cli
-admin@ncs(config-policy-4)# commit dry-run outformat cli
-...
- policy {
- policy-list 1 {
- - action accept;
- + action deny;
- }
- + # after policy-list 3
- + policy-list 4 {
- + srcintf aaa;
- + srcaddr bbb;
- + dstaddr ccc;
- + }
- }
- }
- }
- }
- }
-```
-
-
-
-
-
-This tells the CLI to automatically enter multi-line mode when prompting the user for a value to this leaf. The user must type `` to enter in the multiline mode. For example:
-
-```yang
-leaf message {
- tailf:cli-multi-line-prompt;
- type string;
-}
-```
-
-If configured on the same line, no prompt will appear and it will be rendered as:
-
-```
-(config)# message aaa
-```
-
-If \ typed, it will be rendered as:
-
-```
-(config)# message
-() (aaa):
-[Multiline mode, exit with ctrl-D.]
-> Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
-> Aenean commodo ligula eget dolor. Aenean massa.
-> Cum sociis natoque penatibus et magnis dis parturient montes,
-> nascetur ridiculus mus. Donec quam felis, ultricies nec,
-> pellentesque eu, pretium quis, sem.
->
-(config)# commit
-Commit complete.
-ubuntu(config)# do show running-config message
-message "Lorem ipsum dolor sit amet, consectetuer adipiscing elit. \nAenean
-commodo ligula eget dolor. Aenean massa. \nCum sociis natoque penatibus et
-magnis dis parturient montes, \nnascetur ridiculus mus. Donec quam felis,
-ultricies nec,\n pellentesque eu, pretium quis, sem. \n"
-(config)#
-```
-
-
-
-tailf:cli-multi-line-prompt
-
-This tells the CLI to automatically enter multi-line mode when prompting the user for a value to this leaf. The user must type `
-
-
-
-This statement specifies that the data node should be implemented as a link to another data node, called the target data node. This means that whenever the node is modified, the system modifies the target data node instead, and whenever the data node is read, the system returns the value of the target data node. Note that if the data node is a leaf, the target node MUST also be a leaf, and if the data node is a leaf-list, the target node MUST also be a leaf-list. The argument is an XPath absolute location path. If the target lies within lists, all keys must be specified. A key either has a value or is a reference to a key in the path of the source node, using the function `current()` as a starting point for an XPath location path. For example:
-
-```yang
-container foo {
- list bar {
- key id;
- leaf id {
- type uint32;
- }
- leaf a {
- type uint32;
- }
- leaf b {
- tailf:link "/example:foo/example:bar[id=current()/../id]/example:a";
- type uint32;
- }
- }
-}
-```
-
-It will be rendered as:
-
-```
-(config)# foo bar 1
-ubuntu(config-bar-1)# ?
-Possible completions:
- a
- b
- ---
- commit Commit current set of changes
- describe Display transparent command information
- exit Exit from current mode
- help Provide help information
- no Negate a command or set its defaults
- pwd Display current mode path
- top Exit to top level and optionally run command
-(config-bar-1)# b 100
-(config-bar-1)# show config
-foo bar 1
- b 100
-!
-(config-bar-1)# commit
-Commit complete.
-(config-bar-1)# show full
-foo bar 1
- a 100
- b 100
-!
-(config-bar-1)# a 20
-(config-bar-1)# commit
-Commit complete.
-(config-bar-1)# show full
-foo bar 1
- a 20
- b 20
-!
-```
-
-
diff --git a/development/advanced-development/developing-neds/generic-ned-development.md b/development/advanced-development/developing-neds/generic-ned-development.md
deleted file mode 100644
index 6a4a394f..00000000
--- a/development/advanced-development/developing-neds/generic-ned-development.md
+++ /dev/null
@@ -1,220 +0,0 @@
----
-description: Create generic NEDs.
----
-
-# Generic NED Development
-
-As described in previous sections, the CLI NEDs are almost programming-free. The NSO CLI engine takes care of parsing the stream of characters that come from "show running-config \[toptag]" and also automatically produces the sequence of CLI commands required to take the system from one state to another.
-
-A generic NED is required when we want to manage a device that neither speaks NETCONF or SNMP nor can be modeled so that ConfD - loaded with those models - gets a CLI that looks almost/exactly like the CLI of the managed device. For example, devices that have other proprietary CLIs, devices that can only be configured over other protocols such as REST, Corba, XML-RPC, SOAP, other proprietary XML solutions, etc.
-
-In a manner similar to the CLI NED, the Generic NED needs to be able to connect to the device, return the capabilities, perform changes to the device, and finally, grab the entire configuration of the device.
-
-The interface that a Generic NED has to implement is very similar to the interface of a CLI NED. The main differences are:
-
-* When NSO has calculated a diff for a specific managed device, it will for CLI NEDS also calculate the exact set of CLI commands to send to the device, according to the YANG models loaded for the device. In the case of a generic NED, NSO will instead send an array of operations to perform towards the device in the form of DOM manipulations. The generic NED class will receive an array of `NedEditOp` objects. Each `NedEditOp` object contains:
- * The operation to perform, i.e. CREATED, DELETED, VALUE\_SET, etc.
- * The keypath to the object in case.
- * An optional value
-* When NSO wants to sync the configuration from the device to NSO, the CLI NED only has to issue a series of `show running-config [toptag]` commands and reply with the output received from the device. A generic NED has to do more work. It is given a transaction handler, which it must attach to over the Maapi interface. Then the NED code must - by some means - retrieve the entire configuration and write into the supplied transaction, again using the Maapi interface.
-
-Once the generic NED is implemented, all other functions in NSO work precisely in the same manner as with NETCONF and CLI NED devices. NSO still has the capability to run network-wide transactions. The caveat is that to abort a transaction towards a device that doesn't support transactions, we calculate the reverse diff and send it to the device, i.e. we automatically calculate the undo operations.
-
-Another complication with generic NEDs is how the NED class shall authenticate towards the managed device. This depends entirely on the protocol between the NED class and the managed device. If SSH is used to a proprietary CLI, the existing authgroup structure in NSO can be used as is. However, if some other authentication data is needed, it is up to the generic NED implementer to augment the authgroups in `tailf-ncs.yang` accordingly.
-
-We must also configure a managed device, indicating that its configuration is handled by a specific generic NED. Below we see that the NED with identity `xmlrpc` is handling this device.
-
-```cli
-admin@ncs# show running-config devices device x1
-
-address 127.0.0.1
-port 12023
-authgroup default
-device-type generic ned-id xmlrpc
-state admin-state unlocked
-...
-```
-
-The [examples.ncs/device-management/](https://github.com/NSO-developer/nso-examples/tree/6.6/device-management/xmlrpc-device)[generic-xmlrpc-ned](https://github.com/NSO-developer/nso-examples/tree/6.6/device-management/generic-xmlrpc-ned) example in the NSO examples collection implements a generic NED that speaks XML-RPC to 3 HTTP servers. The HTTP servers run the Apache XML-RPC server code and the NED code manipulates the 3 HTTP servers using a number of predefined XML RPC calls.
-
-A good starting point when we wish to implement a new generic NED is the `ncs-make-package --generic-ned-skeleton ...` command, which is used to generate a skeleton package for a generic NED.
-
-```bash
-$ ncs-make-package --generic-ned-skeleton abc --build
-```
-
-```bash
-$ ncs-setup --ned-package abc --dest ncs
-```
-
-```bash
-$ cd ncs
-```
-
-```bash
-$ ncs -c ncs.conf
-```
-
-```bash
-$ ncs_cli -C -u admin
-```
-
-```cli
-admin@ncs# show packages package abc
-packages package abc
-package-version 1.0
-description "Skeleton for a generic NED"
-ncs-min-version [ 3.3 ]
-component MyDevice
- callback java-class-name [ com.example.abc.abcNed ]
- ned generic ned-id abc
- ned device vendor "Acme abc"
- ...
- oper-status up
-```
-
-## Getting Started with a Generic NED
-
-A generic NED always requires more work than a CLI NED. The generic NED needs to know how to map arrays of `NedEditOp` objects into the equivalent reconfiguration operations on the device. Depending on the protocol and configuration capabilities of the device, this may be arbitrarily difficult.
-
-Regardless of the device, we must always write a YANG model that describes the device. The array of `NedEditOp` objects that the generic NED code gets exposed to is relative the YANG model that we have written for the device. Again, this model doesn't necessarily have to cover all aspects of the device.
-
-Often a useful technique with generic NEDs can be to write a pyang plugin to generate code for the generic NED. Again, depending on the device it may be possible to generate Java code from a pyang plugin that covers most or all aspects of mapping an array of `NedEditOp` objects into the equivalent reconfiguration commands for the device.
-
-Pyang is an extensible and open-source YANG parser (written by Tail-f) available at `http://www.yang-central.org`. pyang is also part of the NSO release. A number of plugins are shipped in the NSO release, for example `$NCS_DIR/lib/pyang/pyang/plugins/tree.py` is a good plugin to start with if we wish to write our own plugin.
-
-The [examples.ncs/device-management/](https://github.com/NSO-developer/nso-examples/tree/6.6/device-management/xmlrpc-device)[generic-xmlrpc-ned](https://github.com/NSO-developer/nso-examples/tree/6.6/device-management/generic-xmlrpc-ned) example is a good example to start with if we wish to write a generic NED. It manages a set of devices over the XML-RPC protocol. In this example, we have:
-
-* Defined a fictitious YANG model for the device.
-* Implemented an XML-RPC server exporting a set of RPCs to manipulate that fictitious data model. The XML-RPC server runs the Apache `org.apache.xmlrpc.server.XmlRpcServer` Java package.
-* Implemented a Generic NED which acts as an XML-RPC client speaking HTTP to the XML-RPC servers.
-
-The example is self-contained, and we can, using the NED code, manipulate these XML-RPC servers in a manner similar to all other managed devices.
-
-```bash
-$ cd $NCS_DIR/device-management/xmlrpc-device
-```
-
-```bash
-$ make all start
-```
-
-```bash
-$ ncs_cli -C -u admin
-```
-
-```cli
-admin@ncs# devices sync-from
-sync-result {
- device r1
- result true
-}
-sync-result {
- device r2
- result true
-}
-sync-result {
- device r3
- result true
-}
-```
-
-```cli
-admin@ncs# show running-config devices r1 config
-
-ios:interface eth0
- macaddr 84:2b:2b:9e:af:0a
- ipv4-address 192.168.1.129
- ipv4-mask 255.255.255.0
- status Up
- mtu 1500
- alias 0
- ipv4-address 192.168.1.130
- ipv4-mask 255.255.255.0
- !
- alias 1
- ipv4-address 192.168.1.131
- ipv4-mask 255.255.255.0
- !
-speed 100
-txqueuelen 1000
-!
-```
-
-### Tweaking the Order of `NedEditOp` Objects
-
-As it was mentioned earlier the `NedEditOp` objects are relative to the YANG model of the device, and they are to be translated into the equivalent reconfiguration operations on the device. Applying reconfiguration operations may only be valid in a certain order.
-
-For Generic NEDs, NSO provides a feature to ensure dependency rules are being obeyed when generating a diff to commit. It controls the order of operations delivered in the `NedEditOp` array. The feature is activated by adding the following option to `package-meta-data.xml`:
-
-```xml
-
-```
-
-When the `ordered-diff` flag is set, the `NedEditOp` objects follow YANG schema order and consider dependencies between leaf nodes. Dependencies can be defined using leafrefs and the _`tailf:cli-diff-after`_, _`tailf:cli-diff-create-after`_, _`tailf:cli-diff-modify-after`_, _`tailf:cli-diff-set-after`_, _`tailf:cli-diff-delete-after`_ YANG extensions. Read more about the above YANG extensions in the Tail-f CLI YANG extensions man page.
-
-## NED Commands
-
-A device we wish to manage using a NED usually has not just configuration data that we wish to manipulate from NSO, but the device usually has a set of commands that do not relate to configuration.
-
-The commands on the device we wish to be able to invoke from NSO must be modeled as actions. We model this as actions and compile it using a special `ncsc` command to compile NED data models that do not directly relate to configuration data on the device.
-
-The [examples.ncs/device-management/](https://github.com/NSO-developer/nso-examples/tree/6.6/device-management/xmlrpc-device)[generic-xmlrpc-ned](https://github.com/NSO-developer/nso-examples/tree/6.6/device-management/generic-xmlrpc-ned) example managed device, a fictitious XML-RPC device, contains a YANG snippet:
-
-```yang
-container commands {
- tailf:action idle-timeout {
- tailf:actionpoint ncsinternal {
- tailf:internal;
- }
- input {
- leaf time {
- type int32;
- }
- }
- output {
- leaf result {
- type string;
- }
- }
- }
-}
-```
-
-When that action YANG is imported into NSO it ends up under the managed device. We can invoke the action _on_ the device as :
-
-```cli
-admin@ncs# devices device r1 config ios:commands idle-timeout time 55
-```
-
-```
-result OK
-```
-
-The NED code is obviously involved here. All NEDs must always implement:
-
-```
-void command(NedWorker w, String cmdName, ConfXMLParam[] params)
- throws NedException, IOException;
-```
-
-The `command()` method gets invoked in the NED, the code must then execute the command. The input parameters in the `params` parameter correspond to the data provided in the action. The `command()` method must reply with another array of `ConfXMLParam` objects.
-
-```java
-public void command(NedWorker worker, String cmdname, ConfXMLParam[] p)
- throws NedException, IOException {
- session.setTracer(worker);
- if (cmdname.compareTo("idle-timeout") == 0) {
- worker.commandResponse(new ConfXMLParam[]{
- new ConfXMLParamValue(new interfaces(),
- "result",
- new ConfBuf("OK"))
- });
- }
-```
-
-The above code is fake, on a real device, the job of the `command()` method is to establish a connection to the device, invoke the command, parse the output, and finally reply with an `ConfXMLParam` array.
-
-The purpose of implementing NED commands is usually that we want to expose device commands to the programmatic APIs in the NSO DOM tree.
diff --git a/development/advanced-development/developing-neds/ned-upgrades-and-migration.md b/development/advanced-development/developing-neds/ned-upgrades-and-migration.md
deleted file mode 100644
index 2eccc65a..00000000
--- a/development/advanced-development/developing-neds/ned-upgrades-and-migration.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-description: Perform NED version upgrades and migration.
----
-
-# NED Upgrades and Migration
-
-Many services in NSO rely on NEDs to perform network provisioning. These services map service-specific configuration to the device data models, provided by the NEDs. As the NED packages can be upgraded independently, they can introduce changes in the device YANG models that cause issues for the services using them.
-
-NSO provides tools to migrate between backward incompatible NED versions. The tools are designed to give you a structured analysis of which paths will change between two NED versions and visibility into the scope of the potential impact that a change in the NED will drive in the service code.
-
-The tools allow for a usage-based analysis of which parts of the NED data model (and instance tree) a particular service has written to. This will give you an (at least opportunistic) sense of which paths must change in the service code.
-
-These features aim to lower the barrier of upgrading NEDs and significantly reduce the amount of uncertainty and side effects that NED upgrades were historically associated with.
-
-## The `migrate` Action
-
-By using the `/ncs:devices/device/migrate` action, you can change the NED major/minor version of a device. The action migrates all configuration and service meta-data. The action can also be executed in parallel on a device group or on all devices matching a NED identity. The procedure for migrating devices is further described in [NED Migration](../../../administration/management/ned-administration.md#sec.ned\_migration).
-
-Additionally, the example [examples.ncs/device-management/ned-migration](https://github.com/NSO-developer/nso-examples/tree/6.6/device-management/ned-migration) in the NSO examples collection illustrates how to migrate devices between different NED versions using the `migrate` action.
-
-What makes it particularly useful to a service developer is that the action reports what paths have been modified and the service instances affected by those changes. This information can then be used to prepare the service code to handle the new NED version. If the `verbose` option is used, all service instances are reported instead of just the service points. If the `dry-run` option is used, the action simply reports what it would do. This gives you the chance to analyze before any actual change is performed.
diff --git a/development/advanced-development/developing-neds/netconf-ned-development.md b/development/advanced-development/developing-neds/netconf-ned-development.md
deleted file mode 100644
index 439cb2ec..00000000
--- a/development/advanced-development/developing-neds/netconf-ned-development.md
+++ /dev/null
@@ -1,653 +0,0 @@
----
-description: Create NETCONF NEDs.
----
-
-# NETCONF NED Development
-
-Creating and installing a NETCONF NED consists of the following steps:
-
-* Make the device YANG data models available to NSO
-* Build the NED package from the YANG data models using NSO tools
-* Install the NED with NSO
-* Configure the device connection and notification events in NSO
-
-Creating a NETCONF NED that uses the built-in NSO NETCONF client can be a pleasant experience with devices and nodes that strictly follow the specification for the NETCONF protocol and YANG mappings to NETCONF. If the device does not, the smooth sailing will quickly come to a halt, and you are recommended to visit the [NED Administration](../../../administration/management/ned-administration.md) in Administration and get help from the Cisco NSO NED team who can diagnose, develop and maintain NEDs that bypass misbehaving devices special quirks.
-
-## Tools for NETCONF NED Development
-
-Before NSO can manage a NETCONF-capable device, a corresponding NETCONF NED needs to be loaded. While no code needs to be written for such NED, it must contain YANG data models for this kind of device. While in some cases, the YANG models may be provided by the device's vendor, devices that implement RFC 6022 YANG Module for NETCONF Monitoring can provide their YANG models using the functionality described in this RFC.
-
-The NSO example under [examples.ncs/device-management/netconf-ned](https://github.com/NSO-developer/nso-examples/tree/6.6/device-management/netconf-ned) implements two shell scripts that use different tools to build a NETCONF NED from a simulated hardware chassis system controller device.
-
-### **The `netconf-console` and `ncs-make-package` Tools**
-
-The `netconf-console` NETCONF client tool is a Python script that can be used for testing, debugging, and simple client duties. For example, making the device YANG models available to NSO using the NETCONF IETF RFC 6022 `get-schema` operation to download YANG modules and the RFC 6241`get` operation, where the device implements the RFC 7895 YANG module library to provide information about all the YANG modules used by the NETCONF server. Type `netconf-console -h` for documentation.
-
-Once the required YANG models are downloaded or copied from the device, the `ncs-make-package` bash script tool can be used to create and build, for example, the NETCONF NED package. See [ncs-make-package(1)](../../../resources/man/ncs-make-package.1.md) in Manual Pages and `ncs-make-package -h` for documentation.
-
-The `demo.sh` script in the `netconf-ned` example uses the `netconf-console` and `ncs-make-package` combination to create, build, and install the NETCONF NED. When you know beforehand which models you need from the device, you often begin with this approach when encountering a new NETCONF device.
-
-### **The NETCONF NED Builder Tool**
-
-The NETCONF NED builder uses the functionality of the two previous tools to assist the NSO developer onboard NETCONF devices by fetching the YANG models from a device and building a NETCONF NED using CLI commands as a frontend.
-
-The `demo_nb.sh` script in the `netconf-ned` example uses the NSO CLI NETCONF NED builder commands to create, build, and install the NETCONF NED. This tool can be beneficial for a device where the YANG models are required to cover the dependencies of the must-have models. Also, devices known to have behaved well with previous versions can benefit from using this tool and its selection profile and production packaging features.
-
-## Using the **`netconf-console`** and **`ncs-make-package`** Combination
-
-For a demo of the steps below, see the README in the [examples.ncs/device-management/netconf-ned](https://github.com/NSO-developer/nso-examples/tree/6.6/device-management/netconf-ned) example and run the demo.sh script.
-
-### **Make the Device YANG Data Models Available to NSO**
-
-List the YANG version 1.0 models the device supports using NETCONF `hello` message.
-
-```bash
-$ netconf-console --port $DEVICE_NETCONF_PORT --hello | grep "module="
-tailf:link target
-
-This statement specifies that the data node should be implemented as a link to another data node, called the target data node. This means that whenever the node is modified, the system modifies the target data node instead, and whenever the data node is read, the system returns the value of the target data node. Note that if the data node is a leaf, the target node MUST also be a leaf, and if the data node is a leaf-list, the target node MUST also be a leaf-list. The argument is an XPath absolute location path. If the target lies within lists, all keys must be specified. A key either has a value or is a reference to a key in the path of the source node, using the function `current()` as a starting point for an XPath location path. For example:
-
-```yang
-container foo {
- list bar {
- key id;
- leaf id {
- type uint32;
- }
- leaf a {
- type uint32;
- }
- leaf b {
- tailf:link "/example:foo/example:bar[id=current()/../id]/example:a";
- type uint32;
- }
- }
-}
-```
-
-It will be rendered as:
-
-```
-(config)# foo bar 1
-ubuntu(config-bar-1)# ?
-Possible completions:
- a
- b
- ---
- commit Commit current set of changes
- describe Display transparent command information
- exit Exit from current mode
- help Provide help information
- no Negate a command or set its defaults
- pwd Display current mode path
- top Exit to top level and optionally run command
-(config-bar-1)# b 100
-(config-bar-1)# show config
-foo bar 1
- b 100
-!
-(config-bar-1)# commit
-Commit complete.
-(config-bar-1)# show full
-foo bar 1
- a 100
- b 100
-!
-(config-bar-1)# a 20
-(config-bar-1)# commit
-Commit complete.
-(config-bar-1)# show full
-foo bar 1
- a 20
- b 20
-!
-```
-
-
SNMP NED Compile Steps
admin@ncs(config)# devices device r1-3 config r:SNMPv2-MIB snmp snmpEnableAuthenTraps enabled
-
MPLS Network
Package Structure
VLAN Service Model Service Point
Java Service Create Callback
Creating the Project in Eclipse
Starting the NSO JVM from Eclipse
Console Output in Eclipse
Connecting to NSO Java VM Remote with Eclipse
Adding the NSO Source Jars
Setting a break-point in Eclipse
Service Create breakpoint
The first Example
Fetching Values from the Service Instance
Iterating a List in the Service Model
The Cisco IOS Model
Setting the VLAN List
Flat Mapping with Java
Two Layered Mapping using Feature Templates
Mapping Logic using a Template
Example L3 VPN Device Configuration
Simple MPLS VPN Topology
L1-L2 Topology
Black-box Topology
The MPLS VPN Example
The MPLS VPN Example
-
-
-
-Check if the configuration created by the service is (still) there. That is, a redeploy of this service would produce no changes.\
-\
-The deep variant also retrieves the latest configuration from all the affected devices, making it relatively expensive.
-
-
-
-check-sync, deep-check-sync actions
-
-Check if the configuration created by the service is (still) there. That is, a redeploy of this service would produce no changes.\
-\
-The deep variant also retrieves the latest configuration from all the affected devices, making it relatively expensive.
-
-
-
-
-
-Re-run the service mapping logic and deploy any changes from the current configuration. The non-reactive variant supports commit parameters, such as dry-run.
-
-The reactive variant performs an asynchronous re-deploy as the user of the original commit and uses the commit parameters from the latest commit of this service. It is often used with nano services, such as restarting a failed nano service.
-
-
-
-re-deploy, reactive-re-deploy actions
-
-Re-run the service mapping logic and deploy any changes from the current configuration. The non-reactive variant supports commit parameters, such as dry-run.
-
-The reactive variant performs an asynchronous re-deploy as the user of the original commit and uses the commit parameters from the latest commit of this service. It is often used with nano services, such as restarting a failed nano service.
-
-
-
-
-
-Remove the configuration produced by the service instance but keep the instance data, allowing a redeploy later. This action effectively deactivates the service while keeping it in the system.
-
-
-
-un-deploy action
-
-Remove the configuration produced by the service instance but keep the instance data, allowing a redeploy later. This action effectively deactivates the service while keeping it in the system.
-
-
-
-
-
-Show the changes in the configuration that this service instance produced. Behaves as if this was the only service that made the changes.
-
-
-
-get-modifications action
-
-Show the changes in the configuration that this service instance produced. Behaves as if this was the only service that made the changes.
-
-
-
-
-
-Available in the configure mode, it marks the service as being changed and allows redeploying multiple services in the same transaction.
-
-
-
-touch action
-
-Available in the configure mode, it marks the service as being changed and allows redeploying multiple services in the same transaction.
-
-
-
-
-
-List devices and services the configuration produced by this service affects directly or indirectly (through other services).
-
-
-
-directly-modified, modified containers
-
-List devices and services the configuration produced by this service affects directly or indirectly (through other services).
-
-
-
-
-
-List of customer services (defined under `/services/customer-service`) that this service is part of. Customer service is an optional concept that allows you to group multiple NSO services as belonging to the same customer.
-
-
-
-used-by-customer-service leaf-list
-
-List of customer services (defined under `/services/customer-service`) that this service is part of. Customer service is an optional concept that allows you to group multiple NSO services as belonging to the same customer.
-
-
-
-
-
-Contains commit queue items related to this service. See [Commit Queue](../../../operation-and-usage/operations/nso-device-manager.md#user_guide.devicemanager.commit-queue) for details.
-
-
-
-commit-queue container
-
-Contains commit queue items related to this service. See [Commit Queue](../../../operation-and-usage/operations/nso-device-manager.md#user_guide.devicemanager.commit-queue) for details.
-
-
-
-
-
-Date and time of the main service events.
-
-
-
-created, last-modified, last-run leafs
-
-Date and time of the main service events.
-
-
-
-
-
-Contains log entries for important service events, such as those related to the commit queue or generated by user code. Defined in `tailf-ncs-log.yang`.
-
-
-
-log container
-
-Contains log entries for important service events, such as those related to the commit queue or generated by user code. Defined in `tailf-ncs-log.yang`.
-
-
-
-
-
-Location of the plan data if the service plan is used. See [Nano Services for Staged Provisioning](../../core-concepts/nano-services.md) for more on service plans and using alternative plan locations.
-
-
-
-While not part of `ncs:service-data` as such, you may consider the `service-commit-queue-event` notification part of the core service interface. The notification provides information about the state of the service when the service uses the commit queue. As an example, an event-driven application uses this notification to find out when a service instance has been deployed to the devices. See the `showcase_rc.py` script in [examples.ncs/scaling-performance/perf-stack](https://github.com/NSO-developer/nso-examples/tree/6.6/scaling-performance/perf-stack) for sample Python code, leveraging the notification. See `tailf-ncs-services.yang` for the full definition of the notification.
-
-NSO Service Manager is responsible for providing the functionality of the common service interface, requiring no additional user code. This interface is the same for classic and nano services, whereas nano services further extend the model.
-
-## Services and Transactions
-
-NSO calls into Service Manager when accessing actions and operational data under the common service interface, or when the service instance configuration data (the data under the service point) changes. NSO being a transactional system, configuration data changes happen in a transaction.
-
-When applied, a transaction goes through multiple stages, as shown by the progress trace (e.g. using `commit | details` in the CLI). The detailed output breaks up the transaction into four distinct phases:
-
-1. validation
-2. write-start
-3. prepare
-4. commit
-
-These phases deal with how the network-wide transactions work:
-
-The validation phase prepares and validates the new configuration (including NSO copy of device configurations), then the CDB processes the changes and prepares them for local storage in the write-start phase.
-
-The prepare stage sends out the changes to the network through the Device Manager and the HA system. The changes are staged (e.g. in the candidate data store) and validated if the device supports it, otherwise, the changes are activated immediately.
-
-If all systems took the new configuration successfully, enter the commit phase, marking the new NSO configuration as active and activating or committing the staged configuration on remote devices. Otherwise, enter the abort phase, discarding changes, and ask NEDs to revert activated changes on devices that do not support transactions (e.g. without candidate data store).
-
-plan-location leaf
-
-Location of the plan data if the service plan is used. See [Nano Services for Staged Provisioning](../../core-concepts/nano-services.md) for more on service plans and using alternative plan locations.
-
-
Typical Transaction Phases
Stages of Transaction Validation Phase
Service Reconciliation
Using the Remote - SSH extension in VS Code
| Level | Description |
|---|---|
normal | Informational messages that highlight the progress of the system at a coarse-grained level. Used mainly to give a high-level overview. This is the default and the lowest verbosity level. |
verbose | Detailed informational messages from the system. The various service and device phases and their duration will be traced. This is useful to get an overview of where time is spent in the system. |
very-verbose | Very detailed informational messages from the system and its internal operations. |
debug | The highest verbosity level with fine-grained informational messages usable for debugging the system and its internal operations. Internal system transactions as well as data kicker evaluation and CDB subscribers will traced. Setting this level could result in a large number of events being generated. |
Running Transactions Sequentially and in Parallel
Designing for Maximal Transaction Throughput
NSO CFS Node
NSO RFS Node 1 (Truncated to Fit)
NSO RFS Node 2 (Truncated to Fit)
| Device Type | RAM | Disk | Number of Devices | Margin | Total RAM | Total Disk |
|---|---|---|---|---|---|---|
| FTTB access switch | 200KiB | 25KiB | 30000 | 100% | 11718MiB | 1464MiB |
| Mobile Base Station | 120KiB | 11KiB | 15000 | 100% | 3515MiB | 322MiB |
| Business CPE | 50KiB | 4KiB | 50000 | 50% | 3662MiB | 292MiB |
| PE / Edge Router | 10MiB | 1MiB | 1000 | 25% | 12GiB | 1.2GiB |
| Total | 20.6GiB | 3.3GiB |
-
-
-
-What are the security characteristics of the JSON-RPC API?
- -JSON-RPC runs on top of the embedded web server (see [Web Server](../../connected-topics/web-server.md)), which accepts HTTP and/or HTTPS. - -The JSON-RPC session ties the client and the server via an HTTP cookie, named `sessionid` which contains a randomly server-generated number. This cookie is not only secure (when the requests come over HTTPS), meaning that HTTPS cookies do not leak over HTTP, but even more importantly, this cookie is also HTTP-only, meaning that only the server and the browser (e.g., not the JavaScript code) have access to the cookie. Furthermore, this cookie is a session cookie, meaning that a browser restart would delete the cookie altogether. - -The JSON-RPC session lives as long as the user does not request to log out, as long as the user is active within a 30-minute (default value, which is configurable) time frame, and as long as there are no severe server crashes. When the session dies, the server will reply with the intention to delete any `sessionid` cookies stored in the browser (to prevent any leaks). - -When used in a browser, the JSON-RPC API does not accept cross-domain requests by default but can be configured to do so via the custom headers functionality in the embedded web server or by adding a reverse proxy (see [Web Server](../../connected-topics/web-server.md)). - -
-
-
-
-What is the proper way to use the JSON-RPC API in a CORS setup?
- -The embedded server allows for custom headers to be set, in this case, CORS headers, like: - -``` -Access-Control-Allow-Origin: http://webpage.com -Access-Control-Allow-Credentials: true -Access-Control-Allow-Headers: Origin, Content-Type, Accept -Access-Control-Request-Method: POST -``` - -A server hosted at `http://server.com` responding with these headers would mean that the JSON-RPC API can be contacted from a browser that is showing a web page from `http://webpage.com`, and will allow the browser to make POST requests, with a limited amount of headers and with credentials (i.e., cookies). - -This is not enough, though, because the browser also needs to be told that your JavaScript code really wants to make a CORS request. A jQuery example would look like this: - -```json -// with jQuery -$.ajax({ - type: 'post', - url: 'http://server.com/jsonrpc', - contentType: 'application/json', - data: JSON.stringify({ - jsonrpc: '2.0', - id: 1, - method: 'login', - params: { - 'user': 'joe', - 'passwd': 'SWkkasE32' - } - }), - dataType: 'json', - crossDomain: true, // CORS specific - xhrFields: { // CORS specific - withCredentials: true // CORS specific - } // CORS specific -}) -``` - -Without this setup, you will notice that the browser will not send the `sessionid` cookie on post-login JSON-RPC calls. - -
-
-
-
-What is a tag/keypath?
- -A `tagpath` is a path pointing to a specific position in a YANG module's schema. - -A `keypath` is a path pointing to a specific position in a YANG module's instance. - -These kinds of paths are used for several of the API methods (e.g., `set_value`, `get_value`, `subscribe_changes`), and could be seen as XPath path specifications in abbreviated format. - -Let's look at some examples using the following YANG module as input: - -```json -module devices { - namespace "http://acme.com/ns/devices"; - prefix d; - - container config { - leaf description { type string; } - list device { - key "interface"; - leaf interface { type string; } - leaf date { type string; } - } - } -} -``` - -Valid tagpaths: - -* `` `/d:config/description` `` -* `` `/d:config/device/interface` `` - -Valid keypaths: - -* `` `/d:config/device{eth0}/date` `` - the date leaf value within a device with an `interface` key set to `eth0`_._ - -Note how the prefix is prepended to the first tag in the path. This prefix is compulsory. - -
-
-
- webui
- webui
- ::jsonrpc:: get_schema
- read exec
- deny
-
-```
-
-Note how the command is prefixed with `::jsonrpc::`. This tells the AAA engine to apply the command rule to JSON-RPC API functions.
-
-You can read more about the command rules in [AAA Infrastructure](../../../administration/management/aaa-infrastructure.md).
-
-
-
-How to restrict access to methods?
- -The AAA infrastructure can be used to restrict access to library functions using command rules: - -```xml -
-
-What is
-
-A series of limits are imposed on the load that one session can put on the system. This reduces the risk that a session takes over the whole system and brings it into a DoS situation.
-
-The response will include details about the limit that triggered the error.
-
-Known limits:
-
-* Only 10,000 commands/subscriptions are allowed per session.
-
-
-
-## Methods
-
-### Commands
-
-What is session.overload error?
-
-A series of limits are imposed on the load that one session can put on the system. This reduces the risk that a session takes over the whole system and brings it into a DoS situation.
-
-The response will include details about the limit that triggered the error.
-
-Known limits:
-
-* Only 10,000 commands/subscriptions are allowed per session.
-
-
-
-
-
-`get_cmds` - Get a list of the session's batch commands.
-
-**Params**
-
-```json
-{}
-```
-
-**Result**
-
-```json
-{"cmds": }
-
-cmd =
- {"params":
-
-get_cmds
-
-`get_cmds` - Get a list of the session's batch commands.
-
-**Params**
-
-```json
-{}
-```
-
-**Result**
-
-```json
-{"cmds":
-
-
-
-`init_cmd` - Starts a batch command.
-
-**Note**: The `start_cmd` method must be called to actually get the batch command to generate any messages unless the `handle` is provided as input.
-
-**Note**: As soon as the batch command prints anything on stdout, it will be sent as a message and turn up as a result to your polling call to the `comet` method.
-
-**Params**
-
-```json
-{"th": ,
- "name": ,
- "args": ,
- "emulate": ,
- "width": ,
- "height": ,
- "scroll": ,
- "comet_id": ,
- "handle": }
-```
-
-* The `name` param is one of the named commands defined in `ncs.conf`.
-* The `args` param specifies any extra arguments to be provided to the command except for the ones specified in `ncs.conf`.
-* The `emulate` param specifies if terminal emulation should be enabled.
-* The `width`, `height`, `scroll` properties define the screen properties.
-
-**Result**
-
-```json
-{"handle": }
-```
-
-A handle to the batch command is returned (equal to `handle` if provided).
-
-
-
-init_cmd
-
-`init_cmd` - Starts a batch command.
-
-**Note**: The `start_cmd` method must be called to actually get the batch command to generate any messages unless the `handle` is provided as input.
-
-**Note**: As soon as the batch command prints anything on stdout, it will be sent as a message and turn up as a result to your polling call to the `comet` method.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`send_cmd_data` - Sends data to batch command started with `init_cmd`_._
-
-**Params**
-
-```json
-{"handle": ,
- "data": }
-```
-
-The `handle` param is as returned from a call to `init_cmd` and the `data` param is what is to be sent to the batch command started with `init_cmd`.
-
-**Result**
-
-```json
-{}
-```
-
-**Errors (specific)**
-
-```json
-{"type": "cmd.not_initialized"}
-```
-
-
-
-send_cmd_data
-
-`send_cmd_data` - Sends data to batch command started with `init_cmd`_._
-
-**Params**
-
-```json
-{"handle":
-
-
-
-`start_cmd` - Signals that a batch command can start to generate output.
-
-**Note**: This method must be called to actually start the activity initiated by calls to one of the methods `init_cmd`.
-
-**Params**
-
-```json
-{"handle": }
-```
-
-The `handle` param is as returned from a call to `init_cmd`.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-start_cmd
-
-`start_cmd` - Signals that a batch command can start to generate output.
-
-**Note**: This method must be called to actually start the activity initiated by calls to one of the methods `init_cmd`.
-
-**Params**
-
-```json
-{"handle":
-
-
-
-`suspend_cmd` - Suspends output from a batch command.
-
-**Note**: the `init_cmd` method must have been called with the `emulate` param set to true for this to work
-
-**Params**
-
-```json
-{"handle": }
-```
-
-The `handle` param is as returned from a call to `init_cmd`.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-suspend_cmd
-
-`suspend_cmd` - Suspends output from a batch command.
-
-**Note**: the `init_cmd` method must have been called with the `emulate` param set to true for this to work
-
-**Params**
-
-```json
-{"handle":
-
-
-
-`resume_cmd` - Resumes a batch command started with `init_cmd`_._
-
-**Note**: the `init_cmd` method must have been called with the `emulate` param set to `true` for this to work.
-
-**Params**
-
-```json
-{"handle": }
-```
-
-The `handle` param is as returned from a call to `init_cmd`.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-resume_cmd
-
-`resume_cmd` - Resumes a batch command started with `init_cmd`_._
-
-**Note**: the `init_cmd` method must have been called with the `emulate` param set to `true` for this to work.
-
-**Params**
-
-```json
-{"handle":
-
-
-
-`stop_cmd` - Stops a batch command.
-
-**Note**: This method must be called to stop the activity started by calls to one of the methods `init_cmd`.
-
-**Params**
-
-```json
-{"handle": }
-```
-
-The `handle` param is as returned from a call to `init_cmd`.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-### Commands - Subscribe
-
-stop_cmd
-
-`stop_cmd` - Stops a batch command.
-
-**Note**: This method must be called to stop the activity started by calls to one of the methods `init_cmd`.
-
-**Params**
-
-```json
-{"handle":
-
-
-
-`get_subscriptions` - Get a list of the session's subscriptions.
-
-**Params**
-
-```json
-{}
-```
-
-**Result**
-
-```json
-{"subscriptions": }
-
-subscription =
- {"params":
-
-get_subscriptions
-
-`get_subscriptions` - Get a list of the session's subscriptions.
-
-**Params**
-
-```json
-{}
-```
-
-**Result**
-
-```json
-{"subscriptions":
-
-
-
-`subscribe_cdboper` - Starts a subscriber to operational data in CDB. Changes done to configuration data will not be seen here.
-
-**Note**: The `start_subscription` method must be called to actually get the subscription to generate any messages unless the `handle` is provided as input.
-
-**Note**: The `unsubscribe` method should be used to end the subscription.
-
-**Note**: As soon as a subscription message is generated it will be sent as a message and turn up as result to your polling call to the `comet` method.
-
-**Params**
-
-```json
-{"comet_id": ,
- "handle": ,
- "path": }
-```
-
-The `path` param is a keypath restricting the subscription messages to only be about changes done under that specific keypath.
-
-**Result**
-
-```json
-{"handle": }
-```
-
-A handle to the subscription is returned (equal to `handle` if provided).
-
-Subscription messages will end up in the `comet` method and the format of that message will be an array of changes of the same type as returned by the `subscribe_changes` method. See below.
-
-**Errors (specific)**
-
-```json
-{"type": "db.cdb_operational_not_enabled"}
-```
-
-
-
-subscribe_cdboper
-
-`subscribe_cdboper` - Starts a subscriber to operational data in CDB. Changes done to configuration data will not be seen here.
-
-**Note**: The `start_subscription` method must be called to actually get the subscription to generate any messages unless the `handle` is provided as input.
-
-**Note**: The `unsubscribe` method should be used to end the subscription.
-
-**Note**: As soon as a subscription message is generated it will be sent as a message and turn up as result to your polling call to the `comet` method.
-
-**Params**
-
-```json
-{"comet_id":
-
-
-
-`subscribe_changes` - Starts a subscriber to configuration data in CDB. Changes done to operational data in CDB data will not be seen here. Furthermore, subscription messages will only be generated when a transaction is successfully committed.
-
-**Note**: The `start_subscription` method must be called to actually get the subscription to generate any messages, unless the `handle` is provided as input.
-
-**Note**: The `unsubscribe` method should be used to end the subscription.
-
-**Note**: As soon as a subscription message is generated, it will be sent as a message and turn up as result to your polling call to the `comet` method.
-
-**Params**
-
-```json
-{"comet_id": ,
- "handle": ,
- "path": ,
- "skip_local_changes": ,
- "hide_changes": ,
- "hide_values": }
-```
-
-The `path` param is a keypath restricting the subscription messages to only be about changes done under that specific keypath.
-
-The `skip_local_changes` param specifies if configuration changes done by the owner of the read-write transaction should generate subscription messages.
-
-The `hide_changes` and `hide_values` params specify a lower level of information in subscription messages, in case it is enough to receive just a "ping" or a list of changed keypaths, respectively, but not the new values resulted in the changes.
-
-**Result**
-
-```json
-{"handle": }
-```
-
-A handle to the subscription is returned (equal to `handle` if provided).
-
-Subscription messages will end up in the `comet` method and the format of that message will be an object such as:
-
-```json
-{"db": <"running" | "startup" | "candidate">,
- "user": ,
- "ip": ,
- "changes": }
-```
-
-The `user` and `ip` properties are the username and IP address of the committing user.
-
-The `changes` param is an array of changes of the same type as returned by the `changes` method. See above.
-
-
-
-subscribe_changes
-
-`subscribe_changes` - Starts a subscriber to configuration data in CDB. Changes done to operational data in CDB data will not be seen here. Furthermore, subscription messages will only be generated when a transaction is successfully committed.
-
-**Note**: The `start_subscription` method must be called to actually get the subscription to generate any messages, unless the `handle` is provided as input.
-
-**Note**: The `unsubscribe` method should be used to end the subscription.
-
-**Note**: As soon as a subscription message is generated, it will be sent as a message and turn up as result to your polling call to the `comet` method.
-
-**Params**
-
-```json
-{"comet_id":
-
-
-
-`subscribe_poll_leaf` - Starts a polling subscriber to any type of operational and configuration data (outside of CDB as well).
-
-**Note**: The `start_subscription` method must be called to actually get the subscription to generate any messages unless the `handle` is provided as input.
-
-**Note**: The `unsubscribe` method should be used to end the subscription.
-
-**Note**: As soon as a subscription message is generated, it will be sent as a message and turn up as result to your polling call to the `comet` method.
-
-**Params**
-
-```json
-{"th": ,
- "path": ,
- "interval": ,
- "comet_id": ,
- "handle": }
-```
-
-The `path` param is a keypath pointing to a leaf value.
-
-The `interval` is a timeout in seconds between when to poll the value.
-
-**Result**
-
-```json
-{"handle": }
-```
-
-A handle to the subscription is returned (equal to `handle` if provided).
-
-Subscription messages will end up in the `comet` method and the format is a simple string value.
-
-
-
-subscribe_poll_leaf
-
-`subscribe_poll_leaf` - Starts a polling subscriber to any type of operational and configuration data (outside of CDB as well).
-
-**Note**: The `start_subscription` method must be called to actually get the subscription to generate any messages unless the `handle` is provided as input.
-
-**Note**: The `unsubscribe` method should be used to end the subscription.
-
-**Note**: As soon as a subscription message is generated, it will be sent as a message and turn up as result to your polling call to the `comet` method.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`subscribe_upgrade` - Starts a subscriber to upgrade messages.
-
-**Note**: The `start_subscription` method must be called to actually get the subscription to generate any messages unless the `handle` is provided as input.
-
-**Note**: The `unsubscribe` method should be used to end the subscription.
-
-**Note**: As soon as a subscription message is generated, it will be sent as a message and turn up as result to your polling call to the `comet` method.
-
-**Params**
-
-```json
-{"comet_id": ,
- "handle": }
-```
-
-**Result**
-
-```json
-{"handle": }
-```
-
-A handle to the subscription is returned (equal to `handle` if provided).
-
-Subscription messages will end up in the `comet` method and the format of that message will be an object such as:
-
-```json
-{"upgrade_state": <"wait_for_init" | "init" | "abort" | "commit">,
- "timeout": }
-```
-
-
-
-subscribe_upgrade
-
-`subscribe_upgrade` - Starts a subscriber to upgrade messages.
-
-**Note**: The `start_subscription` method must be called to actually get the subscription to generate any messages unless the `handle` is provided as input.
-
-**Note**: The `unsubscribe` method should be used to end the subscription.
-
-**Note**: As soon as a subscription message is generated, it will be sent as a message and turn up as result to your polling call to the `comet` method.
-
-**Params**
-
-```json
-{"comet_id":
-
-
-
-`subscribe_jsonrpc_batch` - Starts a subscriber to JSONRPC messages for batch requests.
-
-**Note**: The `start_subscription` method must be called to actually get the subscription to generate any messages unless the `handle` is provided as input.
-
-**Note**: The `unsubscribe` method should be used to end the subscription.
-
-**Note**: As soon as a subscription message is generated it will be sent as a message and turn up as result to your polling call to the `comet` method.
-
-**Params**
-
-```json
-{"comet_id": ,
- "handle": }
-```
-
-**Result**
-
-```json
-{"handle": }
-```
-
-A handle to the subscription is returned (equal to `handle` if provided).
-
-Subscription messages will end up in the `comet` method having exact same structure like a JSON-RPC response:
-
-```json
-{"jsonrpc":"2.0",
- "result":"admin",
- "id":1}
-
-{"jsonrpc": "2.0",
- "id": 1,
- "error":
- {"code": -32602,
- "type": "rpc.method.unexpected_params",
- "message": "Unexpected params",
- "data":
- {"param": "foo"}}}
-```
-
-
-
-subscribe_jsonrpc_batch
-
-`subscribe_jsonrpc_batch` - Starts a subscriber to JSONRPC messages for batch requests.
-
-**Note**: The `start_subscription` method must be called to actually get the subscription to generate any messages unless the `handle` is provided as input.
-
-**Note**: The `unsubscribe` method should be used to end the subscription.
-
-**Note**: As soon as a subscription message is generated it will be sent as a message and turn up as result to your polling call to the `comet` method.
-
-**Params**
-
-```json
-{"comet_id":
-
-
-
-`subscribe_progress_trace` - Starts a subscriber to progress trace events.
-
-**Note**: The `start_subscription` method must be called to actually get the subscription to generate any messages unless the `handle` is provided as input.
-
-**Note**: The `unsubscribe` method should be used to end the subscription.
-
-**Note**: As soon as a subscription message is generated, it will be sent as a message and turn up as result to your polling call to the `comet` method.
-
-**Params**
-
-```json
-{"comet_id": ,
- "handle": ,
- "verbosity": <"normal" | "verbose" | "very_verbose" | "debug", default: "normal">
- "filter_context": <"webui" | "cli" | "netconf" | "rest" | "snmp" | "system" | string, optional>}
-```
-
-The `verbosity` param specifies the verbosity of the progress trace.
-
-The `filter_context` param can be used to only get progress events from a specific context For example, if `filter_context` is set to `cli` only progress trace events from the CLI are returned.
-
-**Result**
-
-```json
-{"handle": }
-```
-
-A handle to the subscription is returned (equal to `handle` if provided).
-
-Subscription messages will end up in the `comet` method and the format of that message will be an object such as:
-
-```json
-{"timestamp": ,
- "duration": ,
- "span-id": ,
- "parent-span-id": ,
- "trace-id": ,
- "session-id": ,
- "transaction-id": ,
- "datastore": ,
- "context": ,
- "subsystem": ,
- "message": ,
- "annotation": ,
- "attributes":
-
-subscribe_progress_trace
-
-`subscribe_progress_trace` - Starts a subscriber to progress trace events.
-
-**Note**: The `start_subscription` method must be called to actually get the subscription to generate any messages unless the `handle` is provided as input.
-
-**Note**: The `unsubscribe` method should be used to end the subscription.
-
-**Note**: As soon as a subscription message is generated, it will be sent as a message and turn up as result to your polling call to the `comet` method.
-
-**Params**
-
-```json
-{"comet_id":
-
-
-
-`start_subscription` - Signals that a subscribe command can start to generate output.
-
-**Note**: This method must be called to actually start the activity initiated by calls to one of the methods `subscribe_cdboper`, `subscribe_changes`, `subscribe_messages`, `subscribe_poll_leaf` or `subscribe_upgrade` \*\*with no `handle`.
-
-**Params**
-
-```json
-{"handle": }
-```
-
-The `handle` param is as returned from a call to `subscribe_cdboper`, `subscribe_changes`, `subscribe_messages`, `subscribe_poll_leaf` or `subscribe_upgrade`.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-start_subscription
-
-`start_subscription` - Signals that a subscribe command can start to generate output.
-
-**Note**: This method must be called to actually start the activity initiated by calls to one of the methods `subscribe_cdboper`, `subscribe_changes`, `subscribe_messages`, `subscribe_poll_leaf` or `subscribe_upgrade` \*\*with no `handle`.
-
-**Params**
-
-```json
-{"handle":
-
-
-
-`unsubscribe` - Stops a subscriber.
-
-**Note**: This method must be called to stop the activity started by calls to one of the methods `subscribe_cdboper`, `subscribe_changes`, `subscribe_messages`, `subscribe_poll_leaf` or `subscribe_upgrade`.
-
-**Params**
-
-```json
-{"handle": }
-```
-
-The `handle` param is as returned from a call to `subscribe_cdboper`, `subscribe_changes`, `subscribe_messages`, `subscribe_poll_leaf` or `subscribe_upgrade`.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-### Data
-
-unsubscribe
-
-`unsubscribe` - Stops a subscriber.
-
-**Note**: This method must be called to stop the activity started by calls to one of the methods `subscribe_cdboper`, `subscribe_changes`, `subscribe_messages`, `subscribe_poll_leaf` or `subscribe_upgrade`.
-
-**Params**
-
-```json
-{"handle":
-
-
-
-`create` - Create a list entry, a presence container, or a leaf of type empty (unless in a union, then use `set_value`).
-
-**Params**
-
-```json
-{"th": ,
- "path": }
-```
-
-The `path` param is a keypath pointing to data to be created.
-
-**Result**
-
-```json
-{}
-```
-
-**Errors (specific)**
-
-```json
-{"type": "db.locked"}
-```
-
-
-
-create
-
-`create` - Create a list entry, a presence container, or a leaf of type empty (unless in a union, then use `set_value`).
-
-**Params**
-
-```json
-{"th":
-
-
-
-`delete` - Deletes an existing list entry, a presence container, or an optional leaf and all its children (if any).
-
-**Note**: If the permission to delete is denied on a child, the 'warnings' array in the result will contain a warning 'Some elements could not be removed due to NACM rules prohibiting access.'. The `delete` method will still delete as much as is allowed by the rules. See [AAA Infrastructure](../../../administration/management/aaa-infrastructure.md) for more information about permissions and authorization.
-
-**Params**
-
-```json
-{"th": ,
- "path": }
-```
-
-The `path` param is a keypath pointing to data to be deleted.
-
-**Result**
-
-```json
-{} |
- {"warnings": }
-```
-
-**Errors (specific)**
-
-```json
-{"type": "db.locked"}
-```
-
-
-
-delete
-
-`delete` - Deletes an existing list entry, a presence container, or an optional leaf and all its children (if any).
-
-**Note**: If the permission to delete is denied on a child, the 'warnings' array in the result will contain a warning 'Some elements could not be removed due to NACM rules prohibiting access.'. The `delete` method will still delete as much as is allowed by the rules. See [AAA Infrastructure](../../../administration/management/aaa-infrastructure.md) for more information about permissions and authorization.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`exists` - Checks if optional data exists.
-
-**Params**
-
-```json
-{"th": ,
- "path": }
-```
-
-The `path` param is a keypath pointing to data to be checked for existence.
-
-**Result**
-
-```json
-{"exists": }
-```
-
-
-
-exists
-
-`exists` - Checks if optional data exists.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`get_case` - Get the case of a choice leaf.
-
-**Params**
-
-```json
-{"th": ,
- "path": ,
- "choice": }
-```
-
-The `path` param is a keypath pointing to data that contains the choice leaf given by the `choice` param.
-
-**Result**
-
-```json
-{"case": }
-```
-
-
-
-get_case
-
-`get_case` - Get the case of a choice leaf.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`show_config` - Retrieves configuration and operational data from the provided transaction. Output can be returned in several formats (CLI, CLI-C, XML, or JSON variants), with optional pagination and filtering to control the breadth and volume of returned data.
-
-**Params**
-
-```json
-{"th": }
-```
-
-```json
-{"path": }
-```
-
-```json
-{"result_as": <"json" | "json2" | "cli" | "cli-c" | "xml", default: "cli">}
-```
-
-```json
-{"with_oper": }
-```
-
-```json
-{"max_size": }
-```
-
-```
-{"depth": }
-```
-
-```
-{"include": }
-```
-
-```
-{"exclude": }
-```
-
-```
-{"offset": }
-```
-
-```
-{"limit": }
-```
-
-The `path` param is a keypath to the configuration to be returned. `result_as` controls the output format; `cli` for CLI curly bracket format, `cli-c` for Cisco CLI style format, `xml` for XML compatible with NETCONF, `json` for JSON compatible with RESTCONF, and `json2` for a variant of the RESTCONF JSON format. `max_size` sets the maximum size of the data field in kB, set to 0 to disable the limit. The `with_oper` param, which controls if the operational data should be included, only takes effect when `result_as` is set to `json` or `json2`. `depth` limits the depth (levels) of the returned subtree below the target `path`. `include` retrieves a subset of nodes below the target `path`, similar to the [RESTCONF fields query parameter](../../core-concepts/northbound-apis/restconf-api.md#d5e1600). `exclude` excludes a subset of nodes below the target `path`, similar to the [RESTCONF exclude query parameter.](../../core-concepts/northbound-apis/restconf-api.md#the-exclude-query-parameter) `offset` controls the number of list elements to skip before returning the requested set of entries. `limit` controls the of list entries to retrieve.
-
-**Result**
-
-The `result_as` param when set to `cli`, `cli-c`, or `xml` :
-
-```json
-{"config": }
-```
-
-The `result_as` param when set to `json` or `json2`:
-
-```json
-{"data": }
-```
-
-
-
-show_config
-
-`show_config` - Retrieves configuration and operational data from the provided transaction. Output can be returned in several formats (CLI, CLI-C, XML, or JSON variants), with optional pagination and filtering to control the breadth and volume of returned data.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`load` - Load XML configuration into the current transaction.
-
-**Params**
-
-```json
-{"th": ,
- "data":
- "path":
- "format": <"json" | "xml", default: "xml">
- "mode": <"create" | "merge" | "replace", default: "merge">}
-```
-
-The `data` param is the data to be loaded into the transaction. `mode` controls how the data is loaded into the transaction, analogous with the CLI command load. `format` informs load about which format `data` is in. If `format` is `xml`, the data must be an XML document encoded as a string. If `format` is `json`, data can either be a JSON document encoded as a string or the JSON data itself.
-
-**Result**
-
-```json
-{}
-```
-
-**Errors (specific)**
-
-```json
-{"row": , "message": }
-```
-
-
-
-### Data - Attributes
-
-load
-
-`load` - Load XML configuration into the current transaction.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`get_attrs` - Get node attributes.
-
-**Params**
-
-```json
-{"th": ,
- "path": ,
- "names": }
-```
-
-The `path` param is a keypath pointing to the node and the `names` param is a list of attribute names that you want to retrieve.
-
-**Result**
-
-```json
-{"attrs":
-
-get_attrs
-
-`get_attrs` - Get node attributes.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`set_attrs` - Set node attributes.
-
-**Params**
-
-```json
-{"th": ,
- "path": ,
- "attrs":
-
-### Data - Leaves
-
-set_attrs
-
-`set_attrs` - Set node attributes.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`get_value` - Gets a leaf value.
-
-**Params**
-
-```json
-{"th": ,
- "path": ,
- "check_default": }
-```
-
-The `path` param is a keypath pointing to a value.
-
-The `check_default` param adds `is_default` to the result if set to `true`. `is_default` is set to `true` if the default value handling returned the value.
-
-**Result**
-
-```json
-{"value": }
-```
-
-**Example**
-
-{% code title="Example: Method get_value" %}
-```bash
-curl \
- --cookie 'sessionid=sess12541119146799620192;' \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "get_value",
- "params": {"th": 4711,
- "path": "/dhcp:dhcp/max-lease-time"}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": {"value": "7200"}
-}
-```
-{% endcode %}
-
-
-
-get_value
-
-`get_value` - Gets a leaf value.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`get_values` - Get leaf values.
-
-**Params**
-
-```json
-{"th": ,
- "path": ,
- "check_default": ,
- "leafs": }
-```
-
-The `path` param is a keypath pointing to a container. The `leafs` param is an array of children names residing under the parent container in the YANG module.
-
-The `check_default` param adds `is_default` to the result if set to `true`. `is_default` is set to `true` if the default value handling returned the value.
-
-**Result**
-
-```json
-{"values": }
-
-value = {"value": , "access": }
-error = {"error": , "access": } |
- {"exists": true, "access": } |
- {"not_found": true, "access": }
-access = {"read": true, write: true}
-```
-
-**Note**: The access object has no `read` and/or `write` properties if there are no read and/or access rights.
-
-
-
-get_values
-
-`get_values` - Get leaf values.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`set_value` - Sets a leaf value.
-
-**Params**
-
-```json
-{"th": ,
- "path": ,
- "value": ,
- "dryrun": }
-```
-
-**Errors (specific)**
-
-```json
-{"type": "data.already_exists"}
-{"type": "data.not_found"}
-{"type": "data.not_writable"}
-{"type": "db.locked"}
-```
-
-**Example**
-
-{% code title="Example: Method set_value" %}
-```bash
-curl \
- --cookie 'sessionid=sess12541119146799620192;' \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "set_value",
- "params": {"th": 4711,
- "path": "/dhcp:dhcp/max-lease-time",
- "value": "4500"}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result": {}
-}
-```
-{% endcode %}
-
-
-
-### Data - Leafref
-
-set_value
-
-`set_value` - Sets a leaf value.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`deref` - Dereferences a leaf with a leafref type.
-
-**Params**
-
-```json
-{"th": ,
- "path": ,
- "result_as": <"paths" | "target" | "list-target", default: "paths">}
-```
-
-The `path` param is a keypath pointing to a leaf with a leafref type.
-
-**Result**
-
-```json
-{"paths": }
-```
-
-```json
-{"target": }
-```
-
-```json
-{"list-target": }
-```
-
-
-
-deref
-
-`deref` - Dereferences a leaf with a leafref type.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`get_leafref_values` - Gets all possible values for a leaf with a leafref type.
-
-**Params**
-
-```json
-{"th": ,
- "path": ,
- "offset": ,
- "limit": ,
- "starts_with": ,
- "skip_grouping": ,
- "keys":
-
-### Data - Lists
-
-get_leafref_values
-
-`get_leafref_values` - Gets all possible values for a leaf with a leafref type.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`rename_list_entry` - Renames a list entry.
-
-**Params**
-
-```json
-{"th": ,
- "from_path": ,
- "to_keys": }
-```
-
-The `from_path` is a keypath pointing out the list entry to be renamed.
-
-The list entry to be renamed will, under the hood, be deleted all together and then recreated with the content from the deleted list entry copied in.
-
-The `to_keys` param is an array with the new key values. The array must contain a full set of key values.
-
-**Result**
-
-```json
-{}
-```
-
-**Errors (specific)**
-
-```json
-{"type": "data.already_exists"}
-{"type": "data.not_found"}
-{"type": "data.not_writable"}
-```
-
-
-
-rename_list_entry
-
-`rename_list_entry` - Renames a list entry.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`copy_list_entry` - Copies a list entry.
-
-**Params**
-
-```json
-{"th": ,
- "from_path": ,
- "to_keys": }
-```
-
-The `from_path` is a keypath pointing out the list entry to be copied.
-
-The `to_keys` param is an array with the new key values. The array must contain a full set of key values.
-
-Copying between different ned-id versions works as long as the schema nodes being copied has not changed between the versions.
-
-**Result**
-
-```json
-{}
-```
-
-**Errors (specific)**
-
-```json
-{"type": "data.already_exists"}
-{"type": "data.not_found"}
-{"type": "data.not_writable"}
-```
-
-
-
-copy_list_entry
-
-`copy_list_entry` - Copies a list entry.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`move_list_entry` - Moves an ordered-by user list entry relative to its siblings.
-
-**Params**
-
-```json
-{"th": ,
- "from_path": ,
- "to_path": ,
- "mode": <"first" | "last" | "before" | "after">}
-```
-
-The `from_path` is a keypath pointing out the list entry to be moved.
-
-The list entry to be moved can either be moved to the first or the last position, i.e. if the `mode` param is set to `first` or `last` the `to_path` keypath param has no meaning.
-
-If the `mode` param is set to `before` or `after` the `to_path` param must be specified, i.e. the list entry will be moved to the position before or after the list entry which the `to_path` keypath param points to.
-
-**Result**
-
-```json
-{}
-```
-
-**Errors (specific)**
-
-```json
-{"type": "db.locked"}
-```
-
-
-
-move_list_entry
-
-`move_list_entry` - Moves an ordered-by user list entry relative to its siblings.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`append_list_entry` - Append a list entry to a leaf-list.
-
-**Params**
-
-```json
-{"th": ,
- "path": ,
- "value": }
-```
-
-The `path` is a keypath pointing to a leaf-list.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-append_list_entry
-
-`append_list_entry` - Append a list entry to a leaf-list.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`count_list_keys` - Counts the number of keys in a list.
-
-**Params**
-
-```json
-{"th":
- "path": }
-```
-
-The `path` parameter is a keypath pointing to a list.
-
-**Result**
-
-```json
-{"count": }
-```
-
-
-
-count_list_keys
-
-`count_list_keys` - Counts the number of keys in a list.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`get_list_keys` - Enumerates keys in a list.
-
-**Params**
-
-```json
-{"th": ,
- "path": ,
- "chunk_size": ,
- "start_with": ,
- "lh": ,
- "empty_list_key_as_null": }
-```
-
-The `th` parameter is the transaction handle.
-
-The `path` parameter is a keypath pointing to a list. Required on first invocation - optional in following.
-
-The `chunk_size` parameter is the number of requested keys in the result. Optional - default is unlimited.
-
-The `start_with` parameter will be used to filter out all those keys that do not start with the provided strings. The parameter supports multiple keys e.g. if the list has two keys, then `start_with` can hold two items.
-
-The `lh` (list handle) parameter is optional (on the first invocation) but must be used in the following invocations.
-
-The `empty_list_key_as_null` parameter controls whether list keys of type empty are represented as the name of the list key (default) or as \`\[null]\`.
-
-**Result**
-
-```json
-{"keys": ,
- "total_count": ,
- "lh": }
-```
-
-Each invocation of `get_list_keys` will return at most `chunk_size` keys. The returned `lh` must be used in the following invocations to retrieve the next chunk of keys. When no more keys are available the returned `lh` will be set to \`-1\`.
-
-On the first invocation `lh` can either be omitted or set to \`-1\`.
-
-
-
-### Data - Query
-
-get_list_keys
-
-`get_list_keys` - Enumerates keys in a list.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`query` - Starts a new query attached to a transaction handle, retrieves the results, and stops the query immediately. This is a convenience method for calling `start_query`, `run_query` and `stop_query` in a one-time sequence.
-
-This method should not be used for paginated results, as it results in performance degradation - use `start_query`, multiple `run_query` and `stop_query` instead.
-
-**Example**
-
-{% code title="Example: Method query" %}
-```bash
-curl \
- --cookie "sessionid=sess11635875109111642;" \
- -X POST \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "query",
- "params": {"th": 1,
- "xpath_expr": "/dhcp:dhcp/dhcp:foo",
- "result_as": "keypath-value"}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result":
- {"current_position": 2,
- "total_number_of_results": 4,
- "number_of_results": 2,
- "number_of_elements_per_result": 2,
- "results": ["foo", "bar"]}}
-```
-{% endcode %}
-
-
-
-query
-
-`query` - Starts a new query attached to a transaction handle, retrieves the results, and stops the query immediately. This is a convenience method for calling `start_query`, `run_query` and `stop_query` in a one-time sequence.
-
-This method should not be used for paginated results, as it results in performance degradation - use `start_query`, multiple `run_query` and `stop_query` instead.
-
-**Example**
-
-{% code title="Example: Method query" %}
-```bash
-curl \
- --cookie "sessionid=sess11635875109111642;" \
- -X POST \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "query",
- "params": {"th": 1,
- "xpath_expr": "/dhcp:dhcp/dhcp:foo",
- "result_as": "keypath-value"}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result":
- {"current_position": 2,
- "total_number_of_results": 4,
- "number_of_results": 2,
- "number_of_elements_per_result": 2,
- "results": ["foo", "bar"]}}
-```
-{% endcode %}
-
-
-
-
-
-`start_query` - Starts a new query attached to a transaction handle. On success, a query handle is returned to be in subsequent calls to `run_query`.
-
-**Params**
-
-```json
-{"th": ,
- "xpath_expr": ,
- "path": ,
- "selection":
- "chunk_size":
- "initial_offset": ,
- "sort", ,
- "sort_order": <"ascending" | "descending", optional>,
- "include_total": ,
- "context_node": ,
- "result_as": <"string" | "keypath-value" | "leaf_value_as_string", default: "string">}
-```
-
-The `xpath_expr` param is the primary XPath expression to base the query on. Alternatively, one can give a keypath as the `path` param, and internally the keypath will be translated into an XPath expression.
-
-A query is a way of evaluating an XPath expression and returning the results in chunks. The primary XPath expression must evaluate to a node-set, i.e. the result. For each node in the result, a `selection` Xpath expression is evaluated with the result node as its context node.
-
-**Note**: The terminology used here is as defined in http://en.wikipedia.org/wiki/XPath.
-
-For example, given this YANG snippet:
-
-```yang
-list interface {
- key name;
- unique number;
- leaf name {
- type string;
- }
- leaf number {
- type uint32;
- mandatory true;
- }
- leaf enabled {
- type boolean;
- default true;
- }
-}
-```
-
-The `xpath_expr` could be \``/interface[enabled='true']`\` and `selection` could be \``{ "name", "number" }`\`.
-
-Note that the `selection` expressions must be valid XPath expressions, e.g. to figure out the name of an interface and whether its number is even or not, the expressions must look like: \``{ "name", "(number mod 2) == 0" }`\`.
-
-The result are then fetched using `run_query`, which returns the result on the format specified by `result_as` param.
-
-There are two different types of results:
-
-* `string` result is just an array with resulting strings of evaluating the `selection` XPath expressions
-* \``keypath-value`\` result is an array the keypaths or values of the node that the `selection` XPath expression evaluates to.
-
-This means that care must be taken so that the combination of `selection` expressions and return types actually yield sensible results (for example \``1 + 2`\` is a valid `selection` XPath expression, and would result in the string `3` when setting the result type to `string` - but it is not a node, and thus have no keypath-value.
-
-It is possible to sort the result using the built-in XPath function \``sort-by()`\` but it is also also possible to sort the result using expressions specified by the `sort` param. These expressions will be used to construct a temporary index which will live as long as the query is active. For example, to start a query sorting first on the enabled leaf, and then on number one would call:
-
-```
-$.post("/jsonrpc", {
- jsonrpc: "2.0",
- id: 1,
- method: "start_query",
- params: {
- th: 1,
- xpath_expr: "/interface[enabled='true']",
- selection: ["name", "number", "enabled"],
- sort: ["enabled", "number"]
- }
-})
- .done(...);
-```
-
-The `context_node` param is a keypath pointing out the node to apply the query on; only taken into account when the `xpath_expr` uses relatives paths. Lack of a `context_node`, turns relatives paths into absolute paths.
-
-The `chunk_size` param specifies how many result entries to return at a time. If set to `0`, a default number will be used.
-
-The `initial_offset` param is the result entry to begin with (`1` means to start from the beginning).
-
-**Result**
-
-```json
-{"qh": }
-```
-
-A new query handler handler id to be used when calling _run\_query_ etc
-
-**Example**
-
-{% code title="Example: Method start_query" %}
-```bash
-curl \
- --cookie "sessionid=sess11635875109111642;" \
- -X POST \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "start_query",
- "params": {"th": 1,
- "xpath_expr": "/dhcp:dhcp/dhcp:foo",
- "result_as": "keypath-value"}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result": 47}
-```
-{% endcode %}
-
-
-
-start_query
-
-`start_query` - Starts a new query attached to a transaction handle. On success, a query handle is returned to be in subsequent calls to `run_query`.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`run_query` - Retrieves the result to a query (as chunks). For more details on queries, read the description of [`start_query`](json-rpc-api.md#start_query).
-
-**Params**
-
-```json
-{"qh": }
-```
-
-The `qh` param is as returned from a call to `start_query`.
-
-**Result**
-
-```json
-{"position": ,
- "total_number_of_results": ,
- "number_of_results": ,
- "chunk_size": ,
- "result_as": <"string" | "keypath-value" | "leaf_value_as_string">,
- "results": }
-
-result = |
- {"keypath": , "value": }
-```
-
-The `position` param is the number of the first result entry in this chunk, i.e. for the first chunk it will be 1.
-
-How many result entries there are in this chunk is indicated by the `number_of_results` param. It will be 0 for the last chunk.
-
-The `chunk_size` and the `result_as` properties are as given in the call to `start_query`.
-
-The `total_number_of_results` param is total number of result entries retrieved so far.
-
-The `result` param is as described in the description of `start_query`.
-
-**Example**
-
-{% code title="Example: Method run_query" %}
-```bash
-curl \
- --cookie "sessionid=sess11635875109111642;" \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "run_query",
- "params": {"qh": 22}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result":
- {"current_position": 2,
- "total_number_of_results": 4,
- "number_of_results": 2,
- "number_of_elements_per_result": 2,
- "results": ["foo", "bar"]}}
-```
-{% endcode %}
-
-
-
-run_query
-
-`run_query` - Retrieves the result to a query (as chunks). For more details on queries, read the description of [`start_query`](json-rpc-api.md#start_query).
-
-**Params**
-
-```json
-{"qh":
-
-
-
-`reset_query` - Reset/rewind a running query so that it starts from the beginning again. The next call to `run_query` will then return the first chunk of result entries.
-
-**Params**
-
-```json
-{"qh": }
-```
-
-The `qh` param is as returned from a call to `start_query`.
-
-**Result**
-
-```json
-{}
-```
-
-**Example**
-
-{% code title="Example: Method reset_query" %}
-```bash
-curl \
- --cookie 'sessionid=sess12541119146799620192;' \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "reset_query",
- "params": {"qh": 67}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result": true}
-```
-{% endcode %}
-
-
-
-reset_query
-
-`reset_query` - Reset/rewind a running query so that it starts from the beginning again. The next call to `run_query` will then return the first chunk of result entries.
-
-**Params**
-
-```json
-{"qh":
-
-
-
-`stop_query` - Stops the running query identified by query handler. If a query is not explicitly closed using this call, it will be cleaned up when the transaction the query is linked to ends.
-
-**Params**
-
-```json
-{"qh": }
-```
-
-The `qh` param is as returned from a call to `start_query`.
-
-**Result**
-
-```json
-{}
-```
-
-**Example**
-
-{% code title="Example: Method stop_query" %}
-```bash
-curl \
- --cookie 'sessionid=sess12541119146799620192;' \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "stop_query",
- "params": {"qh": 67}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result": true}
-```
-{% endcode %}
-
-
-
-### Database
-
-stop_query
-
-`stop_query` - Stops the running query identified by query handler. If a query is not explicitly closed using this call, it will be cleaned up when the transaction the query is linked to ends.
-
-**Params**
-
-```json
-{"qh":
-
-
-
-`reset_candidate_db` - Resets the candidate datastore.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-reset_candidate_db
-
-`reset_candidate_db` - Resets the candidate datastore.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-
-
-`lock_db` - Takes a database lock.
-
-**Params**
-
-```json
-{"db": <"startup" | "running" | "candidate">}
-```
-
-The `db` param specifies which datastore to lock.
-
-**Result**
-
-```json
-{}
-```
-
-**Errors (specific)**
-
-```json
-{"type": "db.locked", "data": {"sessions": }}
-```
-
-The \``data.sessions`\` param is an array of strings describing the current sessions of the locking user, e.g., an array of "admin tcp (cli from 192.245.2.3) on since 2006-12-20 14:50:30 exclusive".
-
-
-
-lock_db
-
-`lock_db` - Takes a database lock.
-
-**Params**
-
-```json
-{"db": <"startup" | "running" | "candidate">}
-```
-
-The `db` param specifies which datastore to lock.
-
-**Result**
-
-```json
-{}
-```
-
-**Errors (specific)**
-
-```json
-{"type": "db.locked", "data": {"sessions":
-
-
-
-`unlock_db` - Releases a database lock.
-
-**Params**
-
-```json
-{"db": <"startup" | "running" | "candidate">}
-```
-
-The `db` param specifies which datastore to unlock.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-unlock_db
-
-`unlock_db` - Releases a database lock.
-
-**Params**
-
-```json
-{"db": <"startup" | "running" | "candidate">}
-```
-
-The `db` param specifies which datastore to unlock.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-
-
-`copy_running_to_startup_db` - Copies the running datastore to the startup datastore.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-### General
-
-copy_running_to_startup_db
-
-`copy_running_to_startup_db` - Copies the running datastore to the startup datastore.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-
-
-`comet` - Listens on a comet channel, i.e. all asynchronous messages from batch commands started by calls to `start_cmd`, `subscribe_cdboper`, `subscribe_changes`, `subscribe_messages`, `subscribe_poll_leaf`, or `subscribe_upgrade` ends up on the comet channel.
-
-You are expected to have a continuous long polling call to the `comet` method at any given time. As soon as the browser or server closes the socket, due to browser or server connect timeout, the `comet` method should be called again.
-
-As soon as the `comet` method returns with values they should be dispatched and the `comet` method should be called again.
-
-**Params**
-
-```json
-{"comet_id": }
-```
-
-**Result**
-
-```
-[{"handle": ,
- "message": },
- ...]
-```
-
-**Errors (specific)**
-
-```json
-{"type": "comet.duplicated_channel"}
-```
-
-**Example**
-
-{% code title="Example: Method comet" %}
-```bash
-curl \
- --cookie 'sessionid=sess12541119146799620192;' \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "subscribe_changes",
- "params": {"comet_id": "main",
- "path": "/dhcp:dhcp"}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result": {"handle": "2"}}
-
-curl \
- --cookie 'sessionid=sess12541119146799620192;' \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "start_cmd",
- "params": {"handle": "2"}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result": {}}
-
-curl \
- -m 15 \
- --cookie 'sessionid=sess12541119146799620192;' \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "comet",
- "params": {"comet_id": "main"}}' \
- http://127.0.0.1:8008/jsonrpc
-```
-{% endcode %}
-
-Hangs, and finally:
-
-```json
-{"jsonrpc": "2.0",
- "id": 1,
- "result":
- [{"handle": "1",
- "message":
- {"db": "running",
- "changes":
- [{"keypath": "/dhcp:dhcp/default-lease-time",
- "op": "value_set",
- "value": "100"}],
- "user": "admin",
- "ip": "127.0.0.1"}}]}
-```
-
-In this case, the admin user seems to have set \`/dhcp:dhcp/default-lease-time\` to 100.
-
-
-
-comet
-
-`comet` - Listens on a comet channel, i.e. all asynchronous messages from batch commands started by calls to `start_cmd`, `subscribe_cdboper`, `subscribe_changes`, `subscribe_messages`, `subscribe_poll_leaf`, or `subscribe_upgrade` ends up on the comet channel.
-
-You are expected to have a continuous long polling call to the `comet` method at any given time. As soon as the browser or server closes the socket, due to browser or server connect timeout, the `comet` method should be called again.
-
-As soon as the `comet` method returns with values they should be dispatched and the `comet` method should be called again.
-
-**Params**
-
-```json
-{"comet_id":
-
-
-
-`get_system_setting` - Extracts system settings such as capabilities, supported datastores, etc.
-
-**Params**
-
-```json
-{"operation": <"capabilities" | "customizations" | "models" | "user" | "version" | "all" | "namespaces", default: "all">}
-```
-
-The `operation` param specifies which system setting to get:
-
-* `capabilities` - the server-side settings are returned, e.g. is rollback and confirmed commit supported.
-* `customizations` - an array of all WebUI customizations.
-* `models` - an array of all loaded YANG modules are returned, i.e. prefix, namespace, name.
-* `user` - the username of the currently logged in user is returned.
-* `version` - the system version.
-* `all` - all of the above is returned.
-* (DEPRECATED) `namespaces` - an object of all loaded YANG modules are returned, i.e. prefix to namespace.
-
-**Result**
-
-```json
-{"user:" ,
- "models:" ,
- "version:" ,
- "customizations": ,
- "capabilities":
- {"rollback": ,
- "copy_running_to_startup": ,
- "exclusive": ,
- "confirmed_commit":
- },
- "namespaces":
-
-get_system_setting
-
-`get_system_setting` - Extracts system settings such as capabilities, supported datastores, etc.
-
-**Params**
-
-```json
-{"operation": <"capabilities" | "customizations" | "models" | "user" | "version" | "all" | "namespaces", default: "all">}
-```
-
-The `operation` param specifies which system setting to get:
-
-* `capabilities` - the server-side settings are returned, e.g. is rollback and confirmed commit supported.
-* `customizations` - an array of all WebUI customizations.
-* `models` - an array of all loaded YANG modules are returned, i.e. prefix, namespace, name.
-* `user` - the username of the currently logged in user is returned.
-* `version` - the system version.
-* `all` - all of the above is returned.
-* (DEPRECATED) `namespaces` - an object of all loaded YANG modules are returned, i.e. prefix to namespace.
-
-**Result**
-
-```json
-{"user:"
-
-
-
-`abort` - Abort a JSON-RPC method by its associated ID.
-
-**Params**
-
-```json
-{"id": }
-```
-
-The `id` param is the id of the JSON-RPC method to be aborted.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-abort
-
-`abort` - Abort a JSON-RPC method by its associated ID.
-
-**Params**
-
-```json
-{"id":
-
-
-
-`eval_XPath` - Evaluates an xpath expression on the server side.
-
-**Params**
-
-```json
-{"th": ,
- "xpath_expr": }
-```
-
-The `xpath_expr` param is the XPath expression to be evaluated.
-
-**Result**
-
-```json
-{"value": }
-```
-
-
-
-### Messages
-
-eval_XPath
-
-`eval_XPath` - Evaluates an xpath expression on the server side.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`send_message` - Sends a message to another user in the CLI or Web UI.
-
-**Params**
-
-```json
-{"to": ,
- "message": }
-```
-
-The `to` param is the user name of the user to send the message to and the `message` param is the actual message.
-
-**Note**: The username `all` will broadcast the message to all users.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-send_message
-
-`send_message` - Sends a message to another user in the CLI or Web UI.
-
-**Params**
-
-```json
-{"to":
-
-
-
-`subscribe_messages` - Starts a subscriber to messages.
-
-**Note**: The `start_subscription` method must be called to actually get the subscription to generate any messages unless the `handle` is provided as input.
-
-**Note**: The `unsubscribe` method should be used to end the subscription.
-
-**Note**: As soon as a subscription message is generated, it will be sent as a message and turn up as a result to your polling call to the `comet` method.
-
-**Params**
-
-```json
-{"comet_id": ,
- "handle": }
-```
-
-**Result**
-
-```xml
-
-```
-
-A handle to the subscription is returned (equal to `handle` if provided).
-
-Subscription messages will end up in the `comet` method and the format of these messages depend on what has happened.
-
-When a new user has logged in:
-
-```json
-{"new_user":
- "me":
- "user": ,
- "proto": <"ssh" | "tcp" | "console" | "http" | "https" | "system">,
- "ctx": <"cli" | "webui" | "netconf">
- "ip": ,
- "login": }
-```
-
-When a user logs out:
-
-```json
-{"del_user": ,
- "user": }
-```
-
-When receiving a message:
-
-```json
-{"sender": ,
- "message": }
-```
-
-
-
-### Schema
-
-subscribe_messages
-
-`subscribe_messages` - Starts a subscriber to messages.
-
-**Note**: The `start_subscription` method must be called to actually get the subscription to generate any messages unless the `handle` is provided as input.
-
-**Note**: The `unsubscribe` method should be used to end the subscription.
-
-**Note**: As soon as a subscription message is generated, it will be sent as a message and turn up as a result to your polling call to the `comet` method.
-
-**Params**
-
-```json
-{"comet_id":
-
-
-
-`get_description` - Get description. To be able to get the description in the response, the `fxs` file needs to be compiled with the flag `--include-doc`. This operation can be heavy so instead of calling get\_description directly, we can confirm that there is a description before calling in `CS_HAS_DESCR` flag that we get from `get_schema` response.
-
-**Params**
-
-```json
-{"th": ,
- "path": }
-```
-
-A `path` is a tagpath/keypath pointing into a specific sub-tree of a YANG module.
-
-**Result**
-
-```json
-{"description": }
-```
-
-
-
-get_description
-
-`get_description` - Get description. To be able to get the description in the response, the `fxs` file needs to be compiled with the flag `--include-doc`. This operation can be heavy so instead of calling get\_description directly, we can confirm that there is a description before calling in `CS_HAS_DESCR` flag that we get from `get_schema` response.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`get_deps` - Retrieve all dependency instances for a specific node instance. There are four sources of dependencies: `must`, `when`, `tailf:display-when` statements, and the `path` statement of a leafref. Each dependency type will be returned separately in its corresponding field: `must`, `when`, `display_when`, and `ref_node`.
-
-**Params**
-
-```json
-{"th": ,
- "path": }
-```
-
-The `path` param is a keypath pointing to an existing node.
-
-**Result**
-
-```json
-{"must": ,
- "when": ,
- "display_when": ,
- "ref_node": }
-```
-
-
-
-get_deps
-
-`get_deps` - Retrieve all dependency instances for a specific node instance. There are four sources of dependencies: `must`, `when`, `tailf:display-when` statements, and the `path` statement of a leafref. Each dependency type will be returned separately in its corresponding field: `must`, `when`, `display_when`, and `ref_node`.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`get_schema` - Exports a JSON schema for a selected part (or all) of a specific YANG module (with optional instance data inserted).
-
-**Params**
-
-```json
-{"th": ,
- "namespace": ,
- "path": ,
- "levels": ,
- "insert_values": ,
- "evaluate_when_entries": ,
- "stop_on_list": ,
- "cdm_namespace": }
-```
-
-One of the properties `namespace` or `path` must be specified.
-
-A `namespace` is as specified in a YANG module.
-
-A `path` is a tagpath/keypath pointing into a specific sub-tree of a YANG module.
-
-The `levels` param limits the maximum depth of containers and lists from which a JSON schema should be produced (-1 means unlimited depth).
-
-The `insert_values` param signals that instance data for leafs should be inserted into the schema. This way the need for explicit forthcoming calls to `get_elem` are avoided.
-
-The `evaluate_when_entries` param signals that schema entries should be included in the schema even though their `when` or `tailf:display-when` statements evaluate to false, i.e. instead a boolean `evaluated_when_entry` param is added to these schema entries.
-
-The `stop_on_list` param limits the schema generation to one level under the list when true.
-
-The `cdm_namespace` param signals the inclusion of `cdm-namespace` entries where appropriate.
-
-**Result**
-
-```json
-{"meta":
- {"namespace": ,
- "keypath": ,
- "prefix": ,
- "types": },
- "data": }
-
-type = : }>
-
-type_stack =
-
-type_stack_entry =
- {"bits": , "size": <32 | 64>} |
- {"leaf_type": , "list_type": } |
- {"union": } |
- {"name": ,
- "info": ,
- "readonly": ,
- "facets": }
-
-primitive_type =
- "empty" |
- "binary" |
- "bits" |
- "date-and-time" |
- "instance-identifier" |
- "int64" |
- "int32" |
- "int16" |
- "uint64" |
- "uint32" |
- "uint16" |
- "uint8" |
- "ip-prefix" |
- "ipv4-prefix" |
- "ipv6-prefix" |
- "ip-address-and-prefix-length" |
- "ipv4-address-and-prefix-length" |
- "ipv6-address-and-prefix-length" |
- "hex-string" |
- "dotted-quad" |
- "ip-address" |
- "ipv4-address" |
- "ipv6-address" |
- "gauge32" |
- "counter32" |
- "counter64" |
- "object-identifier"
-
-facet_entry =
- {"enumeration": {"label": , "info": }} |
- {"fraction-digits": {"value": }} |
- {"length": {"value": }} |
- {"max-length": {"value": }} |
- {"min-length": {"value": }} |
- {"leaf-list": } |
- {"max-inclusive": {"value": }} |
- {"max-length": {"value": }} |
- {"range": {"value": }} |
- {"min-exclusive": {"value": }} |
- {"min-inclusive": {"value": }} |
- {"min-length": {"value": }} |
- {"pattern": {"value": }} |
- {"total-digits": {"value": }}
-
-range_entry =
- "min" |
- "max" |
- |
- [, ]
-
-child =
- {"kind": ,
- "name": ,
- "qname": ,
- "info": ,
- "namespace": ,
- "xml-namespace": ,
- "is_action_input": ,
- "is_action_output": ,
- "is_cli_preformatted": ,
- "is_mount_point":
- "presence": ,
- "ordered_by": ,
- "is_config_false_callpoint": ,
- "key": ,
- "exists": ,
- "value": ,
- "is_leafref": ,
- "leafref_target": ,
- "when_targets": ,
- "deps":
- "hidden": ,
- "default_ref":
- {"namespace": ,
- "tagpath":
- },
- "access":
- {"create": ,
- "update": ,
- "delete": ,
- "execute":
- },
- "config": ,
- "readonly": ,
- "suppress_echo": ,
- "type":
- {"name": ,
- "primitive":
- }
- "generated_name": ,
- "units": ,
- "leafref_groups": ,
- "active": ,
- "cases": ,
- "default": ,
- "mandatory": ,
- "children":
- }
-
-kind =
- "module" |
- "access-denies" |
- "list-entry" |
- "choice" |
- "key" |
- "leaf-list" |
- "action" |
- "container" |
- "leaf" |
- "list" |
- "notification"
-
-case_entry =
- {"kind": "case",
- "name": ,
- "children":
- }
-```
-
-This is a fairly complex piece of JSON but it essentially maps what is seen in a YANG module. Keep that in mind when scrutinizing the above.
-
-The `meta` param contains meta-information about the YANG module such as namespace and prefix but it also contains type stack information for each type used in the YANG module represented in the `data` param. Together with the `meta` param, the `data` param constitutes a complete YANG module in JSON format.
-
-**Example**
-
-{% code title="Example: Method get_schema" %}
-```bash
-curl \
- --cookie "sessionid=sess11635875109111642;" \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "get_schema",
- "params": {"th": 2,
- "path": "/aaa:aaa/authentication/users/user{admin}",
- "levels": -1,
- "insert_values": true}}' \
- http://127.0.0.1:8008/jsonrpc
-{"jsonrpc": "2.0",
- "id": 1,
- "result":
- {"meta":
- {"namespace": "http://tail-f.com/ns/aaa/1.1",
- "keypath": "/aaa:aaa/authentication/users/user{admin}",
- "prefix": "aaa",
- "types":
- {"http://tail-f.com/ns/aaa/1.1:passwdStr":
- [{"name": "http://tail-f.com/ns/aaa/1.1:passwdStr"},
- {"name": "MD5DigestString"}]}}},
- "data":
- {"kind": "list-entry",
- "name": "user",
- "qname": "aaa:user",
- "access":
- {"create": true,
- "update": true,
- "delete": true},
- "children":
- [{"kind": "key",
- "name": "name",
- "qname": "aaa:name",
- "info": {"string": "Login name of the user"},
- "mandatory": true,
- "access": {"update": true},
- "type": {"name": "string", "primitive": true}},
- ...]}}
-```
-{% endcode %}
-
-
-
-get_schema
-
-`get_schema` - Exports a JSON schema for a selected part (or all) of a specific YANG module (with optional instance data inserted).
-
-**Params**
-
-```json
-{"th":
-
-
-
-`hide_schema` - Hides data that has been adorned with a `hidden` statement in YANG modules. `hidden` statement is an extension defined in the tail-common YANG module (http://tail-f.com/yang/common).
-
-**Params**
-
-```json
-{"th": ,
- "group_name": }
-```
-
-The `group_name` param is as defined by a `hidden` statement in a YANG module.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-hide_schema
-
-`hide_schema` - Hides data that has been adorned with a `hidden` statement in YANG modules. `hidden` statement is an extension defined in the tail-common YANG module (http://tail-f.com/yang/common).
-
-**Params**
-
-```json
-{"th":
-
-
-
-`unhide_schema` - Unhides data that has been adorned with a `hidden` statement in the YANG modules. `hidden` statement is an extension defined in the tail-common YANG module (http://tail-f.com/yang/common).
-
-**Params**
-
-```json
-{"th": ,
- "group_name": ,
- "passwd": }
-```
-
-The `group_name` param is as defined by a `hidden` statement in a YANG module.
-
-The `passwd` param is a password needed to hide the data that has been adorned with a `hidden` statement. The password is as defined in the `ncs.conf` file.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-unhide_schema
-
-`unhide_schema` - Unhides data that has been adorned with a `hidden` statement in the YANG modules. `hidden` statement is an extension defined in the tail-common YANG module (http://tail-f.com/yang/common).
-
-**Params**
-
-```json
-{"th":
-
-
-
-`get_module_prefix_map` - Returns a map from module name to module prefix.
-
-**Params**
-
-Method takes no parameters.
-
-**Result**
-
-```xml
-
-
-result = {"module-name": "module-prefix"}
-```
-
-**Example**
-
-{% code title="Example: Method get_module_prefix_map" %}
-```bash
-curl \
- --cookie 'sessionid=sess12541119146799620192;' \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", id: 1,
- "method": "get_module_prefix_map",
- "params": {}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result": {
- "cli-builtin": "cli-builtin",
- "confd_cfg": "confd_cfg",
- "iana-crypt-hash": "ianach",
- "ietf-inet-types": "inet",
- "ietf-netconf": "nc",
- "ietf-netconf-acm": "nacm",
- "ietf-netconf-monitoring": "ncm",
- "ietf-netconf-notifications": "ncn",
- "ietf-netconf-with-defaults": "ncwd",
- "ietf-restconf": "rc",
- "ietf-restconf-monitoring": "rcmon",
- "ietf-yang-library": "yanglib",
- "ietf-yang-types": "yang",
- "tailf-aaa": "aaa",
- "tailf-acm": "tacm",
- "tailf-common-monitoring2": "tfcg2",
- "tailf-confd-monitoring": "tfcm",
- "tailf-confd-monitoring2": "tfcm2",
- "tailf-kicker": "kicker",
- "tailf-netconf-extensions": "tfnce",
- "tailf-netconf-monitoring": "tncm",
- "tailf-netconf-query": "tfncq",
- "tailf-rest-error": "tfrerr",
- "tailf-rest-query": "tfrestq",
- "tailf-rollback": "rollback",
- "tailf-webui": "webui",
- }
-}
-```
-{% endcode %}
-
-
-
-get_module_prefix_map
-
-`get_module_prefix_map` - Returns a map from module name to module prefix.
-
-**Params**
-
-Method takes no parameters.
-
-**Result**
-
-```xml
-
-
-
-
-`run_action` - Invokes an action or RPC defined in a YANG module.
-
-**Params**
-
-```json
-{"th": ,
- "path": ,
- "params":
- "format": <"normal" | "bracket" | "json", default: "normal">,
- "comet_id": ,
- "handle": ,
- "details": <"normal" | "verbose" | "very_verbose" | "debug", optional>}
-```
-
-Actions are as specified in the YANG module, i.e. having a specific name and a well-defined set of parameters and result. The `path` param is a keypath pointing to an action or RPC and the `params` param is a JSON object with action parameters.
-
-The `format` param defines if the result should be an array of key values or a pre-formatted string in bracket format as seen in the CLI. The result is also as specified by the YANG module.
-
-Both a `comet_id` and `handle` need to be provided in order to receive notifications.
-
-The `details` param can be given together with `comet_id` and `handle` in order to get a progress trace for the action. `details` specifies the verbosity of the progress trace. After the action has been invoked, the `comet` method can be used to get the progress trace for the action. If the `details` param is omitted progress trace will be disabled.
-
-The `debug` param can be used the same way as the `details` param to get debug trace events for the action. These are the same trace events that can be displayed in the CLI with the "debug" pipe command when invoking the action. The `debug` param is an array with all debug flags for which debug events should be displayed. Valid values are "service", "template", "xpath", "kicker", and "subscriber". Any other values will result in "invalid params" error. The `debug` param can be used together with the `details` param to get both progress and debug trace events for the operation.
-
-The `debug_service_name` and `debug_template_name` params can be used to specify a service or template name respectively for which to display debug events.
-
-**Note**_:_ This method is often used to call an action that uploads binary data (e.g. images) and retrieving them at a later time. While retrieval is not a problem, uploading is a problem, because JSON-RPC request payloads have a size limitation (e.g. 64 kB). The limitation is needed for performance concerns because the payload is first buffered before the JSON string is parsed and the request is evaluated. When you have scenarios that need binary uploads, please use the CGI functionality instead which has a size limitation that can be configured, and which is not limited to JSON payloads, so one can use streaming techniques.
-
-**Result**
-
-```xml
-
-
-result = {"name": , "value": }
-```
-
-**Errors (specific)**
-
-```json
-{"type": "action.invalid_result", "data": {"path": }}
-```
-
-**Example**
-
-{% code title="Example: Method run_action" %}
-```bash
-curl \
- --cookie 'sessionid=sess12541119146799620192;' \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", id: 1,
- "method": "run_action",
- "params": {"th": 2,
- "path": "/dhcp:dhcp/set-clock",
- "params": {"clockSettings": "2014-02-11T14:20:53.460%2B01:00"}}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result": [{"name":"systemClock", "value":"0000-00-00T03:00:00+00:00"},
- {"name":"inlineContainer/bar", "value":"false"},
- {"name":"hardwareClock","value":"0000-00-00T04:00:00+00:00"}]}
-curl \
- -s \
- --cookie 'sessionid=sess12541119146799620192;' \
- -X POST \
- -H 'Content-Type: application/json' \
- -d'{"jsonrpc": "2.0", "id": 1,
- "method": "run_action",
- "params": {"th": 2,
- "path": "/dhcp:dhcp/set-clock",
- "params": {"clockSettings":
- "2014-02-11T14:20:53.460%2B01:00"},
- "format": "bracket"}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result": "systemClock 0000-00-00T03:00:00+00:00\ninlineContainer {\n \
- bar false\n}\nhardwareClock 0000-00-00T04:00:00+00:00\n"}
-
-curl \
- -s \
- --cookie 'sessionid=sess12541119146799620192;' \
- -X POST \
- -H 'Content-Type: application/json' \
- -d'{"jsonrpc": "2.0", "id": 1,
- "method": "run_action",
- "params": {"th": 2,
- "path": "/dhcp:dhcp/set-clock",
- "params": {"clockSettings":
- "2014-02-11T14:20:53.460%2B01:00"},
- "format": "json"}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result": {"systemClock": "0000-00-00T03:00:00+00:00",
- "inlineContainer": {"bar": false},
- "hardwareClock": "0000-00-00T04:00:00+00:00"}}
-```
-{% endcode %}
-
-
-
-### Session
-
-run_action
-
-`run_action` - Invokes an action or RPC defined in a YANG module.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`login` - Creates a user session and sets a browser cookie.
-
-**Params**
-
-```json
-{}
-```
-
-```json
-{"user": , "passwd": , "ack_warning": }
-```
-
-There are two versions of the `login` method. The method with no parameters only invokes Package Authentication, since credentials can be supplied with the whole HTTP request. The method with parameters is used when credentials may need to be supplied with the method parameters, this method invokes all authentication methods including Package Authentication.
-
-The `user` and `passwd` are the credentials to be used in order to create a user session. The common AAA engine in NSO is used to verify the credentials.
-
-If the method fails with a warning, the warning needs to be displayed to the user, along with a checkbox to allow the user to acknowledge the warning. The acknowledgment of the warning translates to setting `ack_warning` to `true`.
-
-**Result**
-
-```json
-{"warning": }
-```
-
-**Note**_:_ The response will have a \`Set-Cookie\` HTTP header with a `sessionid` cookie which will be your authentication token for upcoming JSON-RPC requests.
-
-The `warning` is a free-text string that should be displayed to the user after a successful login. This is not to be mistaken with a failed login that has a `warning` as well. In case of a failure, the user should also acknowledge the warning, not just have it displayed for optional reading.
-
-**Multi-factor authentication**
-
-```json
-{"challenge_id": , "challenge_prompt": }
-```
-
-**Note**_:_ A challenge response will have a `challenge_id` and `challenge_prompt` which needs to be responded to with an upcoming JSON-RPC `challenge_response` requests.
-
-**Note**: The `challenge_prompt` may be a multi-line, why it is base64 encoded.
-
-**Example**
-
-{% code title="Example: Method login" %}
-```bash
-curl \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "login",
- "params": {"user": "joe",
- "passwd": "SWkkasE32"}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "error":
- {"code": -32000,
- "type": "rpc.method.failed",
- "message": "Method failed"}}
-
-curl \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "login",
- "params": {"user": "admin",
- "passwd": "admin"}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result": {}}
-```
-{% endcode %}
-
-**Note**_:_ `sessionid` cookie is set at this point in your User Agent (browser). In our examples, we set the cookie explicitly in the upcoming requests for clarity.
-
-```bash
-curl \
- --cookie "sessionid=sess4245223558720207078;" \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "get_trans"}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result": {"trans": []}}
-```
-
-
-
-login
-
-`login` - Creates a user session and sets a browser cookie.
-
-**Params**
-
-```json
-{}
-```
-
-```json
-{"user":
-
-
-
-`challenge_response` - Creates a user session and sets a browser cookie.
-
-**Params**
-
-```json
-{"challenge_id": , "response": , "ack_warning": }
-```
-
-The `challenge_id` and `response` is the multi-factor response to be used in order to create a user session. The common AAA engine in NSO is used to verify the response.
-
-If the method fails with a warning, the warning needs to be displayed to the user, along with a checkbox to allow the user to acknowledge the warning. The acknowledgment of the warning translates to setting `ack_warning` to `true`.
-
-**Result**
-
-```json
-{"warning": }
-```
-
-**Note**_:_ The response will have a \`Set-Cookie\` HTTP header with a `sessionid` cookie which will be your authentication token for upcoming JSON-RPC requests.
-
-The `warning` is a free-text string that should be displayed to the user after a successful challenge response. This is not to be mistaken with a failed challenge response that has a `warning` as well. In case of a failure, the user should also acknowledge the warning, not just have it displayed for optional reading.
-
-**Example**
-
-{% code title="Example: Method challenge-response" %}
-```bash
-curl \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "challenge_response",
- "params": {"challenge_id": "123",
- "response": "SWkkasE32"}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "error":
- {"code": -32000,
- "type": "rpc.method.failed",
- "message": "Method failed"}}
-
-curl \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "challenge_response",
- "params": {"challenge_id": "123",
- "response": "SWEddrk1"}}' \
- http://127.0.0.1:8008/jsonrpc
-
- {"jsonrpc": "2.0",
- "id": 1,
- "result": {}}
-```
-{% endcode %}
-
-**Note**_:_ `sessionid` cookie is set at this point in your User Agent (browser). In our examples, we set the cookie explicitly in the upcoming requests for clarity.
-
-```bash
-curl \
- --cookie "sessionid=sess4245223558720207078;" \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "get_trans"}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result": {"trans": []}}
-```
-
-
-
-challenge_response
-
-`challenge_response` - Creates a user session and sets a browser cookie.
-
-**Params**
-
-```json
-{"challenge_id":
-
-
-
-`logout` - Removes a user session and invalidates the browser cookie.
-
-The HTTP cookie identifies the user session so no input parameters are needed.
-
-**Params**
-
-None.
-
-**Result**
-
-```json
-{}
-```
-
-**Example**
-
-{% code title="Example: Method logout" %}
-```bash
-curl \
- --cookie "sessionid=sess4245223558720207078;" \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "logout"}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result": {}}
-
-curl \
- --cookie "sessionid=sess4245223558720207078;" \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "logout"}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "error":
- {"code": -32000,
- "type": "session.invalid_sessionid",
- "message": "Invalid sessionid"}}
-```
-{% endcode %}
-
-
-
-logout
-
-`logout` - Removes a user session and invalidates the browser cookie.
-
-The HTTP cookie identifies the user session so no input parameters are needed.
-
-**Params**
-
-None.
-
-**Result**
-
-```json
-{}
-```
-
-**Example**
-
-{% code title="Example: Method logout" %}
-```bash
-curl \
- --cookie "sessionid=sess4245223558720207078;" \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "logout"}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result": {}}
-
-curl \
- --cookie "sessionid=sess4245223558720207078;" \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "logout"}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "error":
- {"code": -32000,
- "type": "session.invalid_sessionid",
- "message": "Invalid sessionid"}}
-```
-{% endcode %}
-
-
-
-
-
-`kick_user` - Kills a user session, i.e. kicking out the user.
-
-**Params**
-
-```json
-{"user": }
-```
-
-The `user` param is either the username of a logged-in user or session ID.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-### Session Data
-
-kick_user
-
-`kick_user` - Kills a user session, i.e. kicking out the user.
-
-**Params**
-
-```json
-{"user":
-
-
-
-`get_session_data` - Gets session data from the session store.
-
-**Params**
-
-```json
-{"key": }
-```
-
-The `key` param for which to get the stored data for. Read more about the session store in the `put_session_data` method.
-
-**Result**
-
-```json
-{"value": }
-```
-
-
-
-get_session_data
-
-`get_session_data` - Gets session data from the session store.
-
-**Params**
-
-```json
-{"key":
-
-
-
-`put_session_data` - Puts session data into the session store. The session store is a small key-value server-side database where data can be stored under a unique key. The data may be an arbitrary object, but not a function object. The object is serialized into a JSON string and then stored on the server.
-
-**Params**
-
-```json
-{"key": ,
- "value": }
-```
-
-The key param is the unique key for which the data in the `value` param is to be stored.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-put_session_data
-
-`put_session_data` - Puts session data into the session store. The session store is a small key-value server-side database where data can be stored under a unique key. The data may be an arbitrary object, but not a function object. The object is serialized into a JSON string and then stored on the server.
-
-**Params**
-
-```json
-{"key":
-
-
-
-`erase_session_data` - Erases session data previously stored with `put_session_data`.
-
-**Params**
-
-```json
-{"key": }
-```
-
-The `key` param for which all session data will be erased. Read more about the session store in the `put_session_data` method.
-
-**Result**
-
-```json
-{}
-```
-
-
-
-### Transaction
-
-erase_session_data
-
-`erase_session_data` - Erases session data previously stored with `put_session_data`.
-
-**Params**
-
-```json
-{"key":
-
-
-
-`get_trans` - Lists all transactions.
-
-**Params**
-
-None.
-
-**Result**
-
-```json
-{"trans": }
-
-transaction =
- {"db": <"running" | "startup" | "candidate">,
- "mode": <"read" | "read_write", default: "read">,
- "conf_mode": <"private" | "shared" | "exclusive", default: "private">,
- "tag": ,
- "th": }
-```
-
-**Example**
-
-{% code title="Example: Method get_trans" %}
-```bash
-curl \
- --cookie 'sessionid=sess12541119146799620192;' \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "get_trans"}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result":
- {"trans":
- [{"db": "running",
- "th": 2}]}}
-```
-{% endcode %}
-
-
-
-get_trans
-
-`get_trans` - Lists all transactions.
-
-**Params**
-
-None.
-
-**Result**
-
-```json
-{"trans":
-
-
-
-Creates a new transaction.
-
-**Params**
-
-```json
-{"db": <"startup" | "running" | "candidate", default: "running">,
- "mode": <"read" | "read_write", default: "read">,
- "conf_mode": <"private" | "shared" | "exclusive", default: "private">,
- "tag": ,
- "action_path": ,
- "th": ,
- "on_pending_changes": <"reuse" | "reject" | "discard", default: "reuse">}
-```
-
-The `conf_mode` param specifies which transaction semantics to use when it comes to lock and commit strategies. These three modes mimic the modes available in the CLI.
-
-The meaning of `private`, `shared`, and `exclusive` have slightly different meaning depending on how the system is configured; with a writable running, startup, or candidate configuration.
-
-* `private` (\*writable running enabled\*) - Edit a private copy of the running configuration, no lock is taken.
-
-- `private` (\*writable running disabled, startup enabled\*) - Edit a private copy of the startup configuration, no lock is taken.
-
-* `exclusive` (\*candidate enabled\*) - Lock the running configuration and the candidate configuration and edit the candidate configuration.
-
-- `exclusive` (\*candidate disabled, startup enabled\*) - Lock the running configuration (if enabled) and the startup configuration and edit the startup configuration.
-
-* `shared` (\*writable running enabled, candidate enabled\*) - Is a deprecated setting.
-
-The `tag` param is a way to tag transactions with a keyword so that they can be filtered out when you call the `get_trans` method.
-
-The `action_path` param is a keypath pointing to an action or RPC. Use `action_path` when you need to read action/rpc input parameters.
-
-The `th` param is a way to create transactions within other `read_write` transactions. Note that it should always be possible to commit a child transaction (the transaction-in-transaction) to the parent transaction (the original transaction), even if no validation has been done on the child transaction, or if the validation failed due to invalid configuration. Validation on the child transaction is still possible in order to determine if the transaction is valid.
-
-The `on_pending_changes` param decides what to do if the candidate already has been written to, e.g. a CLI user has started a shared configuration session and changed a value in the configuration (without committing it). If this parameter is omitted, the default behavior is to silently reuse the candidate. If `reject` is specified, the call to the `new_trans` method will fail if the candidate is non-empty. If `discard` is specified, the candidate is silently cleared if it is non-empty.
-
-**Result**
-
-```json
-{"th": }
-```
-
-A new transaction handler ID.
-
-**Errors (specific)**
-
-```json
-{"type": "trans.confirmed_commit_in_progress"}
-{"type": "db.locked", "data": {"sessions": }}
-```
-
-The \`data.sessions\` param is an array of strings describing the current sessions of the locking user, e.g., an array of "admin tcp (cli from 192.245.2.3) on since 2006-12-20 14:50:30 exclusive".
-
-**Example**
-
-{% code title="Example: Method new_trans" %}
-```bash
-curl \
- --cookie 'sessionid=sess12541119146799620192;' \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "new_trans",
- "params": {"db": "running",
- "mode": "read"}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result": 2}
-```
-{% endcode %}
-
-
-
-new_trans
-
-Creates a new transaction.
-
-**Params**
-
-```json
-{"db": <"startup" | "running" | "candidate", default: "running">,
- "mode": <"read" | "read_write", default: "read">,
- "conf_mode": <"private" | "shared" | "exclusive", default: "private">,
- "tag":
-
-
-
-`delete_trans` - Deletes a transaction created by `new_trans` or `new_webui_trans`_._
-
-**Params**
-
-```json
-{"th": }
-```
-
-**Result**
-
-```json
-{}
-```
-
-
-
-delete_trans
-
-`delete_trans` - Deletes a transaction created by `new_trans` or `new_webui_trans`_._
-
-**Params**
-
-```json
-{"th":
-
-
-
-`set_trans_comment` - Adds a comment to the active read-write transaction. This comment will be stored in rollback files and can be viewed in the `/rollback:rollback-files/file` list. **Note**: From NSO 6.5 it is recommended to instead use the `comment` flag passed to the `validate_commit` or `apply` method which in addition to storing the comment in the rollback file also propagates it down to the devices participating in the transaction.
-
-**Params**
-
-```json
-{"th": }
-```
-
-**Result**
-
-```json
-{}
-```
-
-
-
-set_trans_comment
-
-`set_trans_comment` - Adds a comment to the active read-write transaction. This comment will be stored in rollback files and can be viewed in the `/rollback:rollback-files/file` list. **Note**: From NSO 6.5 it is recommended to instead use the `comment` flag passed to the `validate_commit` or `apply` method which in addition to storing the comment in the rollback file also propagates it down to the devices participating in the transaction.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`set_trans_label` - Adds a label to the active read-write transaction. This label will be stored in rollback files and can be viewed in the `/rollback:rollback-files/file` list.\
-**Note**: From NSO 6.5 it is recommended to instead use the `label` flag passed to the `validate_commit` or `apply` method which in addition to storing the label in the rollback file also sets it in resulting commit queue items and propagates it down to the devices participating in the transaction.
-
-**Params**
-
-```json
-{"th": }
-```
-
-**Result**
-
-```json
-{}
-```
-
-
-
-### Transaction - Changes
-
-set_trans_label
-
-`set_trans_label` - Adds a label to the active read-write transaction. This label will be stored in rollback files and can be viewed in the `/rollback:rollback-files/file` list.\
-**Note**: From NSO 6.5 it is recommended to instead use the `label` flag passed to the `validate_commit` or `apply` method which in addition to storing the label in the rollback file also sets it in resulting commit queue items and propagates it down to the devices participating in the transaction.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`is_trans_modified` - Checks if any modifications have been done to a transaction.
-
-**Params**
-
-```json
-{"th": }
-```
-
-**Result**
-
-```json
-{"modified": }
-```
-
-
-
-is_trans_modified
-
-`is_trans_modified` - Checks if any modifications have been done to a transaction.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`get_trans_changes` - Extracts modifications done to a transaction.
-
-**Params**
-
-```json
-{"th": },
- "output": <"compact" | "legacy", default: "legacy">
-```
-
-The `output` parameter controls the result content. `legacy` format include old and value for all operation types even if their value is undefined. undefined values are represented by an empty string. `compact` format excludes old and value if their value is undefined.
-
-**Result**
-
-```json
-{"changes": }
-
-change =
- {"keypath": ,
- "op": <"created" | "deleted" | "modified" | "value_set">,
- "value": ,
- "old":
- }
-```
-
-The `value` param is only interesting if `op` is set to one of `modified` or `value_set`.
-
-The `old` param is only interesting if `op` is set to `modified`.
-
-**Example**
-
-{% code title="Example: Method get_trans_changes" %}
-```bash
-curl \
- --cookie 'sessionid=sess12541119146799620192;' \
- -X POST \
- -H 'Content-Type: application/json' \
- -d '{"jsonrpc": "2.0", "id": 1,
- "method": "get_trans_changes",
- "params": {"th": 2}}' \
- http://127.0.0.1:8008/jsonrpc
-
-{"jsonrpc": "2.0",
- "id": 1,
- "result":
- [{"keypath":"/dhcp:dhcp/default-lease-time",
- "op": "value_set",
- "value": "100",
- "old": ""}]}
-```
-{% endcode %}
-
-
-
-get_trans_changes
-
-`get_trans_changes` - Extracts modifications done to a transaction.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`validate_trans` - Validates a transaction.
-
-**Params**
-
-```json
-{"th": }
-```
-
-**Result**
-
-```json
-{}
-```
-
-Or:
-
-```json
-{"warnings": }
-
-warning = {"paths": , "message": }
-```
-
-**Errors (specific)**
-
-```json
-{"type": "trans.resolve_needed", "data": {"users": }}
-```
-
-The `data.users` param is an array of conflicting usernames.
-
-```json
-{"type": "trans.validation_failed", "data": {"errors": }}
-
-error = {"paths": , "message": }
-```
-
-The `data.errors` param points to a keypath that is invalid.
-
-
-
-validate_trans
-
-`validate_trans` - Validates a transaction.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`get_trans_conflicts` - Gets the conflicts registered in a transaction.
-
-**Params**
-
-```json
-{"th": }
-```
-
-**Result**
-
-```json
-{"conflicts:" }
-
-conflict =
- {"keypath": ,
- "op": <"created" | "deleted" | "modified" | "value_set">,
- "value": ,
- "old": }
-```
-
-The `value` param is only interesting if `op` is set to one of `created`, `modified` or `value_set`.
-
-The `old` param is only interesting if `op` is set to `modified`.
-
-
-
-get_trans_conflicts
-
-`get_trans_conflicts` - Gets the conflicts registered in a transaction.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`resolve_trans` - Tells the server that the conflicts have been resolved.
-
-**Params**
-
-```json
-{"th": }
-```
-
-**Result**
-
-```json
-{}
-```
-
-
-
-### Transaction - Commit Changes
-
-resolve_trans
-
-`resolve_trans` - Tells the server that the conflicts have been resolved.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`validate_commit` - Validates a transaction before calling `commit`. If this method succeeds (with or without warnings) then the next operation must be a call to either `commit` or `clear_validate_lock`. The configuration will be locked for access by other users until one of these methods is called.
-
-**Params**
-
-```json
-{"th": }
-```
-
-```json
-{"comet_id": }
-```
-
-```json
-{"handle": }
-```
-
-```json
-{"details": <"normal" | "verbose" | "very_verbose" | "debug", optional>}
-```
-
-```json
-{"debug": }
-debug_flags = <"service" | "template" | "xpath" | "kicker" | "subscriber">
-```
-
-```json
-{"debug_service_name": }
-```
-
-```json
-{"debug_template_name": }
-```
-
-```json
-{"flags": }
-flags =
-```
-
-The `comet_id`, `handle`, and `details` params can be given together in order to get progress tracing for the `validate_commit` operation. The same `comet_id` can also be used to get the progress trace for any coming commit operations. In order to get progress tracing for commit operations, these three parameters have to be provided with the `validate_commit` operation. The `details` parameter specifies the verbosity of the progress trace. After the operation has been invoked, the `comet` method can be used to get the progress trace for the operation.
-
-The `debug` param can be used the same way as the `details` param to get debug trace events for the validate\_commit and corresponding commit operation. These are the same trace events that can be displayed in the CLI with the "debug" pipe command for the commit operation. The `debug` param is an array with all debug flags for which debug events should be displayed. The `debug` param can be used together with the `details` param to get both progress and debug trace events for the operation.
-
-The `debug_service_name` and `debug_template_name` params can be used to specify a service or template name respectively for which to display debug events.
-
-See the `commit` method for available flags.
-
-**Note**: If you intend to pass `flags` to the `commit` method, it is recommended to pass the same `flags` to `validate_commit` since they may have an effect during the validate step.
-
-**Result**
-
-```json5
-{}
-```
-
-Or:
-
-```json
-{"warnings": }
-warning = {"paths": , "message": }
-```
-
-**Errors (specific)**
-
-Same as for the `validate_trans` method.
-
-
-
-validate_commit
-
-`validate_commit` - Validates a transaction before calling `commit`. If this method succeeds (with or without warnings) then the next operation must be a call to either `commit` or `clear_validate_lock`. The configuration will be locked for access by other users until one of these methods is called.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`clear_validate_lock` - Releases validate lock taken by `validate_commit`.
-
-**Params**
-
-```json
-{"th": }
-```
-
-**Result**
-
-```json5
-{}
-```
-
-
-
-clear_validate_lock
-
-`clear_validate_lock` - Releases validate lock taken by `validate_commit`.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`commit` - Commits the configuration into the running datastore.
-
-**Params**
-
-```json
-{"th": }
-```
-
-```json
-{"release_locks": }
-```
-
-```json
-{"rollback-id": }
-```
-
-```json
-{"flags": }
-flags =
-```
-
-If `rollback-id` is set to `true`, the response will include the ID of the rollback file created during the commit if any.
-
-Commit behavior can be changed via an extra `flags` param:
-
-The `flags` param is a list of flags that can change the commit behavior:
-
-* `label=LABEL` - Sets a user-defined label that is visible in rollback files, compliance reports, notifications, and events referencing the transaction and resulting commit queue items. If supported, the label will also be propagated down to the devices participating in the transaction.
-* `comment=COMMENT` - Sets a comment visible in rollback files and compliance reports. If supported, the comment will also be propagated down to the devices participating in the transaction.
-* `dry-run=FORMAT` - Where FORMAT is the desired output format: `xml`, `cli`, or `native`. Validate and display the configuration changes but do not perform the actual commit. Neither CDB nor the devices are affected. Instead, the effects that would have taken place is shown in the returned output.
-* `dry-run-reverse` - Used with the dry-run=native flag this will display the device commands for getting back to the current running state in the network if the commit is successfully executed. Beware that if any changes are done later on the same data the reverse device commands returned are invalid.
-* `confirm-network-state`\
- NSO will check network state as part of the commit. This includes checking device configurations for out-of-band changes and processing such changes according to the out-of-band policy.
-* `confirm-network-state=re-evaluate-policies`\
- In addition to processing the newly found out-of-band device changes, NSO will process again the out-of-band policies for the services that the commit is touching.
-
-- `no-revision-drop` - NSO will not run its data model revision algorithm, which requires all participating managed devices to have all parts of the data models for all data contained in this transaction. Thus, this flag forces NSO to never silently drop any data set operations towards a device.
-- `no-overwrite` - NSO will check that the modified data and the data read when computing the device modifications have not changed on the device compared to NSO's view of the data. Can't be used with no-out-of-sync-check.
-- `no-networking` - Do not send data to the devices; this is a way to manipulate CDB in NSO without generating any southbound traffic.
-- `no-out-of-sync-check` - Continue with the transaction even if NSO detects that a device's configuration is out of sync. It can't be used with no-overwrite.
-- `no-deploy` - Commit without invoking the service create method, i.e., write the service instance data without activating the service(s). The service(s) can later be redeployed to write the changes of the service(s) to the network.
-- `reconcile=OPTION` - Reconcile the service data. All data which existed before the service was created will now be owned by the service. When the service is removed that data will also be removed. In technical terms, the reference count will be decreased by one for everything that existed prior to the service. If manually configured data exists below in the configuration tree, that data is kept unless the option `discard-non-service-config` is used.
-- `use-lsa` - Force handling of the LSA nodes as such. This flag tells NSO to propagate applicable commit flags and actions to the LSA nodes without applying them on the upper NSO node itself. The commit flags affected are `dry-run`, `no-networking`, `no-out-of-sync-check`, `no-overwrite` and `no-revision-drop`.
-- `no-lsa` - Do not handle any of the LSA nodes as such. These nodes will be handled as any other device.
-- `commit-queue=MODE` - Where MODE is: `async`, `sync`, or `bypass`. Commit the transaction data to the commit queue.
- * If the `async` value is set, the operation returns successfully if the transaction data has been successfully placed in the queue.
- * The `sync` value will cause the operation to not return until the transaction data has been sent to all devices, or a timeout occurs.
- * The `bypass` value means that if `/devices/global-settings/commit-queue/enabled-by-default` is `true`, the data in this transaction will bypass the commit queue. The data will be written directly to the devices.
-- `commit-queue-atomic=ATOMIC` - Where `ATOMIC` is: `true` or `false`. Sets the atomic behavior of the resulting queue item. If `ATOMIC` is set to `false`, the devices contained in the resulting queue item can start executing if the same devices in other non-atomic queue items ahead of it in the queue are completed. If set to `true`, the atomic integrity of the queue item is preserved.
-- `commit-queue-block-others` - The resulting queue item will block subsequent queue items, that use any of the devices in this queue item, from being queued.
-- `commit-queue-lock` - Place a lock on the resulting queue item. The queue item will not be processed until it has been unlocked, see the actions `unlock` and `lock` in `/devices/commit-queue/queue-item`. No following queue items, using the same devices, will be allowed to execute as long as the lock is in place.
-- `commit-queue-tag=TAG` - Where `TAG` is a user-defined opaque tag. The tag is present in all notifications and events sent referencing the specific queue item.\
- **Note**: `commit-queue-tag` is deprecated from NSO version 6.5. The `label` flag can be used instead.
-- `commit-queue-timeout=TIMEOUT` - Where `TIMEOUT` is infinity or a positive integer. Specifies a maximum number of seconds to wait for the transaction to be committed. If the timer expires, the transaction data is kept in the commit queue, and the operation returns successfully. If the timeout is not set, the operation waits until completion indefinitely.
-- `commit-queue-error-option=OPTION` - Where `OPTION` is: `continue-on-error`, `rollback-on-error` or `stop-on-error`. Depending on the selected error option NSO will store the reverse of the original transaction to be able to undo the transaction changes and get back to the previous state. This data is stored in the `/devices/commit-queue/completed` tree from where it can be viewed and invoked with the `rollback` action. When invoked, the data will be removed.
- * The `continue-on-error` value means that the commit queue will continue on errors. No rollback data will be created.
- * The `rollback-on-error` value means that the commit queue item will roll back on errors. The commit queue will place a lock with `block-others` on the devices and services in the failed queue item. The `rollback` action will then automatically be invoked when the queue item has finished its execution. The lock is removed as part of the rollback.
- * The `stop-on-error` means that the commit queue will place a lock with `block-others` on the devices and services in the failed queue item. The lock must then either manually be released when the error is fixed or the `rollback` action under `/devices/commit-queue/completed` be invoked.
-
- **Note**: Read about error recovery in [Commit Queue](../../../operation-and-usage/operations/nso-device-manager.md#user_guide.devicemanager.commit-queue) for a more detailed explanation.
-- `trace-id=TRACE_ID` - Use the provided trace ID as part of the log messages emitted while processing. If no trace ID is given, NSO is going to generate and assign a trace ID to the processing.\
- **Note**: `trace-id` is deprecated from NSO version 6.3. Capabilities within Trace Context will provide support for `trace-id`, see the section [TraceContext](json-rpc-api.md#trace-context).
-
-**Note**: Must be preceded by a call to `validate_commit`_._
-
-**Note**: The transaction handler is deallocated as a side effect of this method.
-
-**Result**
-
-Successful commit without any arguments.
-
-```json5
-{}
-```
-
-Successful commit with `rollback-id=true`:
-
-```json
-{"rollback-id": {"fixed": 10001}}
-```
-
-Successful commit with `commit-queue=async`:
-
-```json
-{"commit_queue_id": }
-```
-
-The `commit_queue_id` is returned if the commit entered the commit queue, either by specifying `commit-queue=async` or by enabling it in the configuration.
-
-
-
-commit
-
-`commit` - Commits the configuration into the running datastore.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`apply` - Performs validate, prepare and commit/abort in one go.
-
-**Params**
-
-```json
-{"th": }
-```
-
-```json
-{"comet_id": }
-```
-
-```json
-{"handle": }
-```
-
-```json
-{"details": <"normal" | "verbose" | "very_verbose" | "debug", optional>}
-```
-
-```json
-{"debug": }
-debug_flags = <"service" | "template" | "xpath" | "kicker" | "subscriber">
-```
-
-```json
-{"debug_service_name": }
-```
-
-```json
-{"debug_service_name": }
-```
-
-```json
-{"flags": }
-flags =
-```
-
-The `comet_id`, `handle`, and `details` params can be given together in order to get progress tracing for the operation. The `details` parameter specifies the verbosity of the progress trace. After the operation has been invoked, the `comet` method can be used to get the progress trace for the operation.
-
-The `debug` param can be used the same way as the `details` param to get debug trace events. These are the same trace events that can be displayed in the CLI with the "debug" pipe command for the commit operation. The `debug` param is an array with all debug flags for which debug events should be displayed. The `debug` param can be used together with the `details` param to get both progress and debug trace events for the operation.
-
-The `debug_service_name` and `debug_template_name` params can be used to specify a service or template name respectively for which to display debug events.
-
-See the `commit` method for available flags.
-
-**Result**
-
-See result for method `commit`.
-
-
-
-### Transaction - Web UI
-
-apply
-
-`apply` - Performs validate, prepare and commit/abort in one go.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`get_webui_trans` - Gets the WebUI read-write transaction.
-
-**Result**
-
-```json
-{"trans": }
-
-trans =
- {"db": <"startup" | "running" | "candidate", default: "running">,
- "conf_mode": <"private" | "shared" | "exclusive", default: "private">,
- "th":
- }
-```
-
-
-
-get_webui_trans
-
-`get_webui_trans` - Gets the WebUI read-write transaction.
-
-**Result**
-
-```json
-{"trans":
-
-
-
-`new_webui_trans` - Creates a read-write transaction that can be retrieved by `get_webui_trans`.
-
-**Params**
-
-```json
-{"db": <"startup" | "running" | "candidate", default: "running">,
- "conf_mode": <"private" | "shared" | "exclusive", default: "private">
- "on_pending_changes": <"reuse" | "reject" | "discard", default: "reuse">}
-```
-
-See `new_trans` for the semantics of the parameters and specific errors.
-
-The `on_pending_changes` param decides what to do if the candidate already has been written to, e.g. a CLI user has started a shared configuration session and changed a value in the configuration (without committing it). If this parameter is omitted, the default behavior is to silently reuse the candidate. If `reject` is specified, the call to the `new_webui_trans` method will fail if the candidate is non-empty. If `discard` is specified, the candidate is silently cleared if it is non-empty.
-
-**Result**
-
-```json
-{"th": }
-```
-
-A new transaction handler ID.
-
-
-
-### Services
-
-new_webui_trans
-
-`new_webui_trans` - Creates a read-write transaction that can be retrieved by `get_webui_trans`.
-
-**Params**
-
-```json
-{"db": <"startup" | "running" | "candidate", default: "running">,
- "conf_mode": <"private" | "shared" | "exclusive", default: "private">
- "on_pending_changes": <"reuse" | "reject" | "discard", default: "reuse">}
-```
-
-See `new_trans` for the semantics of the parameters and specific errors.
-
-The `on_pending_changes` param decides what to do if the candidate already has been written to, e.g. a CLI user has started a shared configuration session and changed a value in the configuration (without committing it). If this parameter is omitted, the default behavior is to silently reuse the candidate. If `reject` is specified, the call to the `new_webui_trans` method will fail if the candidate is non-empty. If `discard` is specified, the candidate is silently cleared if it is non-empty.
-
-**Result**
-
-```json
-{"th":
-
-
-
-`get_template_variables` - Extracts all variables from an NSO service/device template.
-
-**Params**
-
-```json
-{"th": ,
- "name": }
-```
-
-The `name` param is the name of the template to extract variables from.
-
-**Result**
-
-```json
-{"template_variables": }
-```
-
-
-
-get_template_variables
-
-`get_template_variables` - Extracts all variables from an NSO service/device template.
-
-**Params**
-
-```json
-{"th":
-
-
-
-`get_service_points` - List all service points. To be able to get the description part of the response the fxs files needs to be compiled with the flag "--include-doc".
-
-**Result**
-
-```json
-{"description": ,
- "keys": ,
- "path": }
-```
-
-
-
-### Packages
-
-get_service_points
-
-`get_service_points` - List all service points. To be able to get the description part of the response the fxs files needs to be compiled with the flag "--include-doc".
-
-**Result**
-
-```json
-{"description":
-
-
-
-`list_packages` - Lists packages in NSO.
-
-**Params**
-
-```json
-{"status": <"installable" | "installed" | "loaded" | "all", default: "all">}
-```
-
-The `status` param specifies which package status to list:
-
-* `installable` - an array of all packages that can be installed.
-* `installed` - an array of all packages that are installed, but not loaded.
-* `loaded` - an array of all loaded packages.
-* `all` - all of the above is returned.
-
-**Result**
-
-```json
-{"packages": }
-```
-
-
diff --git a/development/connected-topics/README.md b/development/connected-topics/README.md
deleted file mode 100644
index 5e78a72f..00000000
--- a/development/connected-topics/README.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-description: Miscellaneous topics connected to NSO development.
-icon: object-intersect
----
-
-# Connected Topics
-
diff --git a/development/connected-topics/encryption-keys.md b/development/connected-topics/encryption-keys.md
deleted file mode 100644
index 0dae6080..00000000
--- a/development/connected-topics/encryption-keys.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-description: Manage and work with NSO encrypted strings.
----
-
-# Encrypted Strings
-
-By using the NSO built-in encrypted YANG extension types `tailf:aes-cfb-128-encrypted-string` or `tailf:aes-256-cfb-128-encrypted-string`, it is possible to store encrypted string values in NSO that can be decrypted. See the [tailf\_yang\_extensions(5)](../../resources/man/tailf_yang_extensions.5.md#yang-types-2) man page for more details on the encrypted string YANG extension types.
-
-## Decrypting the Encrypted Strings
-
-Encrypted string values can only be decrypted using `decrypt()`, when NSO is running with the correct [cryptographic keys](../../administration/advanced-topics/cryptographic-keys.md). Python example:
-
-```python
-import ncs
-import _ncs
-# Install the crypto keys used to decrypt the string
-with ncs.maapi.Maapi() as maapi:
- maapi.install_crypto_keys(maapi.msock)
-# Decrypt the string
-my_decrypted_str = _ncs.decrypt(my_encrypted_str)
-```
-
-## Reading Encryption Keys using an External Command
-
-NSO supports reading encryption keys using an external command instead of storing them in `ncs.conf` to allow for use with external key management systems. For `ncs.conf` details, see the [ncs.conf(5) man page](../../resources/man/ncs.conf.5.md) under `/ncs-config/encrypted-strings`.
-
-To use this feature, set `/ncs-config/encrypted-strings/external-keys/command` to an executable command that will output the keys following the rules described in the following sections. The command will be executed on startup and when NSO reloads the configuration.
-
-If the external command fails during startup, the startup will abort. If the command fails during a reload, the error will be logged, and the previously loaded keys will be kept in the system.
-
-The process of providing encryption keys to NSO can be described by the following three steps:
-
-1. Read the configuration from the environment.
-2. Read encryption keys.
-3. Write encryption keys (or error on standard output).
-
-The value of `/ncs-config/encrypted-strings/external-keys/command-argument` is available in the command as the environment variable `NCS_EXTERNAL_KEYS_ARGUMENT`. The value of this configuration is only used by the configured command.
-
-The external command should return the encryption keys on standard output using the names as shown in the table below. The encryption key values are in hexadecimal format, just as in `ncs.conf`. See the example below for details.
-
-The following table shows the mapping from the name to the path in the configuration.
-
-list_packages
-
-`list_packages` - Lists packages in NSO.
-
-**Params**
-
-```json
-{"status": <"installable" | "installed" | "loaded" | "all", default: "all">}
-```
-
-The `status` param specifies which package status to list:
-
-* `installable` - an array of all packages that can be installed.
-* `installed` - an array of all packages that are installed, but not loaded.
-* `loaded` - an array of all loaded packages.
-* `all` - all of the above is returned.
-
-**Result**
-
-```json
-{"packages": | Name | Configuration path |
|---|---|
AESCFB128_KEY | /ncs-config/encrypted-strings/AESCFB128/key |
AES256CFB128_KEY | /ncs-config/encrypted-strings/AES256CFB128/key |
SNMP NED Compile Steps
| MAAPI (Management Agent API) Northbound interface that is transactional and user session-based. Using this interface both configuration and operational data can be read. Configuration data can be written and committed as one transaction. The API is complete in the way that it is possible to write a new northbound agent using only this interface. It is also possible to attach to ongoing transactions in order to read uncommitted changes and/or modify data in these transactions. |  |
| CDB API The southbound interface provides access to the CDB configuration database. Using this interface configuration data can be read. In addition, operational data that is stored in CDB can be read and written. This interface has a subscription mechanism to subscribe to changes. A subscription is specified on a path that points to an element in a YANG model or an instance in the instance tree. Any change under this point will trigger the subscription. CDB has also functions to iterate through the configuration changes when a subscription has been triggered. |  |
| DP API Southbound interface that enables callbacks, hooks, and transforms. This API makes it possible to provide the service callbacks that handle service-to-device mapping logic. Other usual cases are external data providers for operational data or action callback implementations. There are also transaction and validation callbacks, etc. Hooks are callbacks that are fired when certain data is written and the hook is expected to do additional modifications of data. Transforms are callbacks that are used when complete mediation between two different models is necessary. |  |
| NED API (Network Element Driver) Southbound interface that mediates communication for devices that do not speak either NETCONF or SNMP. All prepackaged NEDs for different devices are written using this interface. It is possible to use the same interface to write your own NED. There are two types of NEDs, CLI NEDs and Generic NEDs. CLI NEDs can be used for devices that can be controlled by a Cisco-style CLI syntax, in this case the NED is developed primarily by building a YANG model and a relatively small part in Java. In other cases the Generic NED can be used for any type of communication protocol. |  |
| NAVU API (Navigation Utilities) API that resides on top of the Maapi and Cdb APIs. It provides schema model navigation and instance data handling (read/write). Uses either a Maapi or Cdb context as data access and incorporates a subset of functionality from these (navigational and data read/write calls). Its major use is in service implementations which normally is about navigating device models and setting device data. |  |
| ALARM API Eastbound API that is used both to consume and produce alarms in alignment with the NSO Alarm model. To consume alarms the AlarmSource interface is used. To produce a new alarm the AlarmSink interface is used. There is also a possibility to buffer produced alarms and make asynchronous writes to CDB to improve alarm performance. |  |
| NOTIF API Northbound API that is used to subscribe to system events from NSO. These events are generated for audit log events, for different transaction states, for HA state changes, upgrade events, user sessions, etc. |  |
| HA API (High Availability) Northbound api used to manage a High Availability cluster of NSO instances. An NSO instance can be in one of three states NONE, PRIMARY or SECONDARY. With the HA API the state can be queried and changed for NSO instances in the cluster. |  |
NSO Transaction State Machine