Persistent Configuration Repository¶

All configuration for SRTC components should be stored in the Persistent Configuration Repository. The purpose is to store all possible configurations for each Deployment Set centrally and in a persistent manner. The user normally prepares all necessary configuration in the Persistent Configuration Repository rather than interacting with the Runtime Configuration Repository. The configuration values for the active Deployment Set are then copied from the Persistent Configuration Repository to the Runtime Configuration Repository automatically by the RTC Supervisor.

Note

Currently only a simple file based Persistent Configuration Repository is available. The Persistent Configuration Repository is not yet implemented using the full CII configuration service for the current release of the RTC Toolkit, version 1.0.0. Major changes are expected in the CII configuration service API. Therefore this will only be integrated after the changes once the API has stabilised.

Deployment Sets are also not being handled yet. The configuration stored in the Persistent Configuration Repository is copied directly as is into the Runtime Configuration Repository, which effectively gives a 1-to-1 mapping.

In the future, the intention is that the Persistent Configuration Repository is backed by the CII configuration service and that Deployment Sets are handled, meaning only the relevant values for the active Deployment Set will be copied into the Runtime Configuration Repository. See section 4.6.2.3 “Configuration Repositories” in the RTC Toolkit Design document for further details about the intended structure of the repositories.

Modifying the Configuration¶

The user should use rtctkConfigTool to interact with the configuration in the file based Persistent Configuration Repository. See section Configuration Tool for a general description of how to use the tool. Alternatively, the underlying files stored on disk can be accessed directly to prepare the configuration. The YAML file format was chosen to make direct manipulation easier. In addition, FITS files can be used for large vectors and matrices.

The following sub-sections will give brief examples that are more specific to manipulating the Persistent Configuration Repository with rtctkConfigTool.

Datapoint Paths¶

Configuration parameters are stored in a tree hierarchy as leaf nodes in the Persistent Configuration Repository. This can also be thought of as a folder like structure, similar to a file system. The nodes from the root of the tree to a particular leaf node form the components of a path. By adding the ‘/’ character as the path separator between each component, this forms a datapoint path string.

The current canonical structure for the path is as follows:

/<component>/{static,dynamic}/<parameter>

Where <component> will typically be the SRTC component instance name and <parameter> can represent a hierarchical sub-path with multiple sub-folders if a deeper hierarchy of configuration parameters is desired for a particular SRTC component, besides the basic grouping into static and dynamic parameters.

Path components must contain only lowercase alpha numeric characters or the underscore, i.e. characters from the set [a-z0-9_].

Note

The canonical path structure indicated in this section will change once Deployment Sets are fully supported in future releases of RTC Toolkit. Currently it replicates exactly the structure used in the Runtime Configuration Repository.

Datapoint Reading¶

The following is an example of reading a parameter called flatimg, which is a matrix, into a local file called flatimg.fits for the component datatask1:

$ rtctkConfigTool --repo file:/home/eltdev/persistent_repo \
                  --path /datatask1/static/flatimg \
                  --read --file flatimg.fits

In this case, the location of the repository in the local file system is /home/eltdev/persistent_repo, i.e. this is the base directory.

Datapoint Writing¶

The following is an example of writing the contents of a local FITS file called flatimg.fits, which contains a matrix of floating-point doubles, into a parameter called flatimg for the component datatask1:

$ rtctkConfigTool --repo file:/home/eltdev/persistent_repo \
                  --path /datatask1/static/flatimg \
                  --write --file flatimg.fits \
                  --type RtcMatrixDouble

It is possible to subsequently manipulate the data directly in the local file system, in this case, under the location /home/eltdev/persistent_repo.

If the datapoint does not exist it is created automatically. Otherwise it is updated with the new value.

Datapoint Querying¶

Use the following command to list all datapoints or sub-paths under a certain path, in this case /datatask1/static:

$ rtctkConfigTool --repo file:/home/eltdev/persistent_repo \
                  --path /datatask1/static --list

The data type for a particular datapoint can be queried with the following command:

$ rtctkConfigTool --repo file:/home/eltdev/persistent_repo \
                  --path /datatask1/static/flatimg --get-type

Service Discovery Endpoint¶

The supported URI scheme for the service discovery parameter persist_repo_endpoint is currently only file. For example file:/home/eltdev/persistent_repo.

Data Access Using the API¶

Note

SRTC components should not access the Persistent Configuration Repository directly. Only a limited subset of components and tools should use the API to modify the Persistent Configuration Repository. See the section Modifying the Configuration for details about the typical manner to update the Persistent Configuration Repository.

The API for accessing datapoints is identical to the Runtime Configuration Repository. The only differences are that the Persistent Configuration Repository does not support the datapoint subscription API, and the interface class to use is the PersistentRepoIf, which is fetched from the Service Discovery as follows:

auto oldb = m_services.Get<PersistentRepoIf>();

Refer to the Data Access sub-section of Runtime Configuration Repository for details about the methods for creating, reading, writing, deleting and querying datapoints.

Supported Data Types¶

The same data types are supported as for the Runtime Configuration Repository. Refer to the Supported Data Types sub-section of Runtime Configuration Repository for further details.

File Format¶

The current Persistent Configuration Repository implementation uses the same internal file format as the file based Runtime Configuration Repository. Refer to the File Format sub-section of Runtime Configuration Repository for further details.

Limitations and Known Issues¶

The same limitation currently apply to the Persistent Configuration Repository repository as the file based Runtime Configuration Repository. Refer to the Limitations and Known Issues sub-section of Runtime Configuration Repository for further details.