Controlling the virtual circuit identifier (vcid) with service_id¶

Each deployment of a CarrierEthernetEvc using LDP backend will need to receive an unused vcid. This id is then used for configurations such as the Epipe and sdp id. This value is not passed on via the API, the model will receive it through allocation. The allocator is given a range of values that can be used, it is aware of the values it has already allocated and based on this and the allocation strategy (next, for sequential allocation, or any, for random allocation) will pick the allocated vcid.

The user of the module can influence the behavior of the allocator with three parameters in the configuration file:

carrier_ethernet_evc.service_id.start: The lowest value that can be allocated.
carrier_ethernet_evc.service_id.end: The highest value that can be allocated.
carrier_ethernet_evc.service_id.strategy: The strategy to use when selecting the next allocated value. Possible values are:
- next: Select the first free value in the range.
- any: Select any free value in the range.

Controlling the ethernet virtual interconnect (evi) with service_id¶

Each deployment of a CarrierEthernetEvc using EVPN backend will need to receive an unused evi. This id is then used for configs such as the Epipe and evi id. This value is not passed on via the API, the model will receive it through allocation. The allocator is given a range of values that can be used, it is aware of the values it has already allocated and based on this and the allocation strategy (next, for sequential allocation, or any, for random allocation) will pick the allocated evi.

The behavior of the allocator can be influenced similar to the vcid, by editing the carrier_ethernet_evc.service_id part of the configuration.

Generating A Default Configuration File¶

Running the following command will generate a default configuration file using the configuration plugin:

python connect/docs/configuration/new_conf.py <path_to_store_config_file>

For example:

python connect/docs/configuration/new_conf.py /home/user/connect-project/files/connect-config.yaml

Special values¶

Most of the configuration fields accept a specific primitive type while others have stricter requirements. Moreover, two additional types which are of primitive constraints are introduced:

InmantaTemplatePath: A path, prefixed by ‘template://’. The rest of the string is a path to a file in an inmanta project or module.
- If the path starts with /, the path is in the project’s folder. For example, template:///example/inventory.yaml points to a file located in templates/example/inventory.yaml at the root of the project using this module.
- If the path doesn’t start with /, the part of the string before the first / is the name of the module in the files of which the inventory is located. For example, template://example/inventory.yaml points to a file located in templates/inventory.yaml at the root of the module named example.
SystemPath: A string prefixed by file://. The rest of the string should be an absolute path to a file on the system where the compiler is running.

Using templates¶

Some configuration fields accept a path to a template located in an inmanta module or project. Those fields accept a value of type InmantaTemplatePath, and can also accept a simpler value of a primitive type. In the former case, the path should point to a Jinja2 template (the extension of the file doesn’t matter, but the content does). This template will be rendered at compile time when calling one of the get_config_template_value plugins (there is one by primitive type of the inmanta language). The values used for the rendering are provided in the plugin parameters.

Example: A template has already been added to this module: nokia/epipe_service_name.j2.

The template path to reach it is: inmanta://connect/templates/nokia/epipe_service_name.j2. This is the default value of nokia.epipe_service_name in the configuration.
The template content is epipe-{{ vcid }}
This template is used to generate the name of the Epipe service, from the vcid.
In the model, the template is rendered and accessed like this:
```
config::get_config_template_value_as_string(
    connect::config,
    "nokia.epipe_service_name",
    instance=self,
    kwargs={
        "vcid": vc_id,
    },
),
```
The plugins takes four parameters:
- config: The full config, from which the element at :param dict_path: should be queried.
- dict_path: The path to the configuration value in which the template path should be found.
- instance: (Optional) An inmanta instance, in this case the one in which implementation we call the plugin from.
- kwargs: (Optional) A dict, containing key-value pairs, values can only be inmanta primitive types (no entities).