NVP Tool Overview
The NVP is designed to help customers change, retrieve and apply the configuration changes to UFM parameter settings within config files. NVP aims to simplify the process, sparing users from manually editing the config files. It is important to note that NVP follows a transactional model approach, changing/setting the configuration on temporary files. These changes are only integrated into the configuration upon executing the apply command. The tool supports three file types:
flat config: Refers to files that only have key-value pairs
ini: Refers to files that have sections associated with key-value pairs
xml: Refers to XML formatted files
It is important to note that the current version of NVP does not facilitate adding new configurations to existing configuration files. The tool is provided as a plugin and can be operated either as a standalone application using Docker commands or invoked through CLI commands. All the examples provided below illustrate the usage of NVP via CLI.
The tool supports the following functionalities:
set
get
dump
apply
help
Please note that the tool's plugin operates without a running daemon. Upon adding the plugin via the plugin infrastructure, its status remains "stopped" signifying its inactive state without a daemon. However, when a user initiates NVP (either through standalone Docker usage or via the CLI commands), the image activates, executes the command, performs the necessary operations, and then exits.
The Set API is designed to change the configuration of a file based on the key-value pair provided by the user. It updates the specified key with a new value. If the given key is not found, the NVP tool generates an error indicating 'key not found'. Additionally, NVP refrains from making any changes if the new value for the key is identical to the old one. It is important to note that both the key and value are case sensitive.
Refer to TBD: link for command specifications.
An example of SET API that would change qos value to TRUE for opensm.conf(flat config) would be:
nvp set opensm.conf qos TRUE
Similarly, for INI
nvp set gv.cfg GarbageCollector.enable false
For XML files, a valid xpath must be provided. Few examples of SET for a XML config are: NOTE: The xpath must be enclosed in double-quotes for NVP to function.
nvp set UFMHealthConfiguration.xml "./TestsSchedule/Test[@Name='CheckMgmtInterface']/Frequency/Value" 20
nvp set UFMHealthConfiguration.xml "./SupportedTests/Test[@Name='CpuUsageTest']/TestOperation[@Name='CPUTest']/Parameters/Parameter[@Name='ThresholdInPercents']/Value" 120
NOTE: It is important to note that, there might be situation where file names are same but files are present in the different location. In this case, NVP expects file name to include its parent directory. For example, file launch_ibdiagnet_config.ini is present both in secondary_telemetry_defaults and telemetry_defaults. If user want to modify the file present in secondary_telemetry_defaults, command should look like below:
nvp set secondary_telemetry_defaults/launch_ibdiagnet_config.ini <key> <val>
To set an empty value using SET, empty string can be passed while using SET. Example:
nvp set gv.cfg Multisubnet.multisubnet_role ""
The Get API aims to retrieve the configuration of file based on the key entered by the user. In case, NVP is not able to find the given key, NVP throws an error of 'key not found'. It is important to note that, GET API retrieves the value from the transactional configuration. It means, only the files whose configuration has been changed by the user using the SET API will be visible to the GET API. Note that the key is case sensitive.
Refer to TBD: link for command specifications.
An example of GET API that would retrieve qos from opensm.conf(flat config) would be:
nvp get opensm.conf qos
Similarly, for INI
nvp get gv.cfg GarbageCollector.enable
For XML files, a valid xpath must be provided. Few examples of GET for a XML config are:
nvp get UFMHealthConfiguration.xml ./TestsSchedule/Test[@Name="CheckMgmtInterface"]/Frequency/Value
nvp get UFMHealthConfiguration.xml ./SupportedTests/Test[@Name='CpuUsageTest']/TestOperation[@Name='CPUTest']/Parameters/Parameter[@Name='ThresholdInPercents']/Value
The NVP dump generates a single json file. The generated json file contains the configuration of all the NVP supported configuration files as json objects dumped in one single json. Content/configuration of each file is appended, overall to create a combined json structure. The order in the json dump aligns with that of the original configuration file.
Refer to TBD: link for command specifications.
The Apply API is a 2 step process. First, the NVP Apply moves all the files that have been changed via SET API to their original location. The second step involves re-starting the UFM Server so that the new changes take effect. Moving of changed files from transaction folder to the actual location is independent of UFM server being down or any error occurs while re-starting the UFM server. NVP does not support of roll-back in case UFM restart is not successful. So, the first step of APPLY API is independent of the success/failure 2nd step(UFM restart). Ofcourse, if an error occurs in the first step, NVP APPLY would throw an appropriate error and exit with trying to restart the UFM.
NOTE: A prompt is displayed for user if they would like to continue or not with this action as the API involves UFM restart. The API expects the below syntax:
Refer to TBD: link for command specifications.
To not receive any prompts user may use force option. This will restart the UFM without any prompt. The syntax for the same is:
Refer to TBD: link for command specifications.