PY-SIL Introduction
The PY-SIL subsystem provides sub-agent support for SIL-SA callbacks. It uses messages between the server and subsystem to distribute SIL operations across multiple remote subsystems.
Note
This feature is available starting in version 23.10T-9
PY-SIL Limitations
Below is a list of PY-SIL limitations, detailing unsupported features, callbacks, and other options that are not currently supported.
No Key Map Set Key Map Set
No in-Transaction Callbacks In-Transaction Callbacks
No EDIT2 callbacks, only EDIT3
No make_silsa anymore, now pyang plugin is used
No Apply Path inside RPC/Actions DataStore Edit APIs For RPC SIL Callbacks
No NMDA support for GET2 callbacks Instrumentation Changes for NMDA
No Data Structure Typedef Constants Data Structure Typedef Constants
Only full modules are supported in PY-SIL automatic code generation.
No Schema Mount Support Schema Mount Server APIs
No combo app support.
PY-SIL Getting Started
Prior to using PY-SIL, it must be installed. A comprehensive installation guide is available, covering all scenarios. The following guide will provide instructions for a minimal installation suitable for the introductory walk-through.
PY-SIL Development Environment
PY-SIL Code Generation
The py-sil-gen.py plugin for pyang library can be used to generate PY-SIL code-stub files for the netconfd-pro server.
You can find more information here PY-SIL Code Generation
PY-SIL Library Names
PY-SIL libraries must be named with a predictable string in order for the server to find it with minimal configuration.
PY-SIL Library Location
The --pymodpath CLI parameter of 'py-sil-app' application is needed to specify locations for PY-SIL library files.
Note
If the --pymodpath CLI parameter is not provided, the default search path for PY-SIL library files is $HOME/pysil directory. If it is not found in this default location the application will attempt to locate PY-SIL in the current directory.
PY-SIL Usage
Note
PY-SIL libraries can only be used within the py-sil-app.
Check comprehensive PY-SIL callback reference for callback usage examples PY-SIL Callback Reference
py-sil-app
The py-sil-app program provides a complete functioning application for implementing YANG object callback functions in a subsystem. It provides complete functionality for the PY-SIL Subsystem. The netconfd-pro program must be built with the make flag WITH_YCONTROL=1.
YANG Modules in the PY-SIL Subsystem
There are several ways that a subsystem can be deployed in the server platform. Any combination of the following is allowed:
One or more subsystems located on the same host as netconfd-pro
Each subsystem is often used with the --library parameter to select PY-SIL libraries from a common library location
One or more subsystems located on a different host than netconfd-pro
Each subsystem is often used with overlapping YANG modules.
It is possible for each subsystem to handle different instances in the same YANG list.
The main requirement is that each subsystem register a different subsystem identifier (see --subsys-id for details).
When a subsystem starts up, the server informs the subsystem of all the modules and bundles configured to be loaded into the server. By default, a subsystem will attempt to load every module or bundle in this list.
The --library CLI parameter can be used by each subsystem to limit the libraries that are loaded.
Example: Subsystems on the Same Host as netconfd-pro
Assume each subsystem is intended to implement a different bundle.
> # in each of 3 terminal windows
> netconfd-pro --bundle=bundle1 --bundle=bundle2
> py-sil-app --subsys-id=subsys1 --library=bundle1
> py-sil-app --subsys-id=subsys2 --library=bundle2
It is possible for multiple subsystems and the main module to register for the same object. Each callback must decide if it should handle the specific instance being requested (E.g. interface “eth0” or “eth3”). Subsystems need to return 'ok' for any edit request it ignores, and return 'no-instance' for any GET2 requests for unsupported instances.
Note
In a system where multiple subsystems can register for the same list object, there are specific behaviors to note when the list lacks defined keys in YANG. In such cases, the server will accept responses from all registered subsystems. Importantly, it will use the response from the last responding subsystem for the <get> response. This "last one wins" approach means that the final subsystem's response takes precedence and is reflected in the <get> response output.
In the registration phase, the main server will send the complete module and bundle parameter list to each subsystem. Each subsystem will load its SIL-SA library code as required for that subsystem.
It is up to the developer to make sure each subsystem registers with the main server with a unique subsys-id string. Only one subsystem can use the default (subsys1), The --subsys-id CLI parameter can be used to set the subsystem identifier.
PY-SIL API Functions
PY-SIL provides pysil library with classes that are needed to implement your own PY-SIL code. Check this PY-SIL API Reference
PY-SIL Message Format
The same as in regular SIL-SA