Creating device configurations before starting the lab

[ipspace]

Associated with this, some node/provider types can support a different provisioning model where the config file is bind-mounted to a container (instead of executed after bringing up the node)

For example, in Containerlab there is a 'startup-config' option that could point to a generated file - but this is currently not possible due to the order of processing steps.

Perhaps we could generalize the model, separate the generation of the config file from its deployment and allow providers/nodes to indicate which provisioning model is desired?

Containerlab builds a directory structure with a subdir for each node, and puts the (initial) config there. The config can be updated and saved to the same place, providing an easy way to save the configs of the complete topology. Something similar would be helpful for netsim-tools (instead of using temporary files and throwing them away, as is currently done)

Originally posted by @jbemmel in https://github.com/ipspace/netsim-tools/issues/77#issuecomment-997411545

[ipspace]

@jbemmel: What you're looking for is doable, and I have no problems with another device flag and a Jinja2 template transformation performed before the lab is started.

The question is whether you really want it. I decided to deploy non-immutable configuration snippets to avoid the situation where multiple modules (for example) need to change parameters of the same interface (here's an example: https://blog.ipspace.net/2020/12/ansible-config-sections.html).

Ansible no longer wrecks the device configuration when faced with that challenge, but Cisco IOS reinitializes interface configuration every time it encounters interface in configure replace input file, and other platforms that use text configurations instead of Junos-like data models might do the same.

Creating a configuration file where you have to mix numerous inputs (parameters of different configurable protocols) under the same configuration object (interface) is an awesome waste of time resulting in a fantastic spaghetti mess. I did it in the past, and I don't want to repeat that mistake ;)

[jbemmel]

@ipspace funny, I feel the same about using Ansible as a provisioning framework in general (did it in the past) But I decided to humor your choices ;)

However, what I have in mind doesn't fundamentally change what's already being done. You have the 'initial' module generating an initial config (~delta). Then you have other modules which essentially apply incremental changes to that, i.e. the configuration is mutable which is what you need.

I'm proposing we keep the modularity with different modules for different protocols, but we would add the option of generating an initial config that is an aggregation of those (same) modular snippets. Not another Jinja2 template, but a composition of existing ones. As you discovered, you'd have to consolidate (merge) the snippets such that a given interface appears only once - but that's doable, at least for the format I'm using (lists of OpenConfig update/replace/delete snippets)

It may not work for all devices, just the properly architected ones...

[ipspace]

Hey, I "love" Ansible as much as anyone who had to deal with it beyond a few simple tasks ;)) It's just that most everything else is worse.

How about this (more details if you like the idea):

• New config output module.
• The config output module would be one of the default output modules executed by netlab create (together with provider and ansible)
• For device types where defaults.devices.type.startup_config is set (to a Jinja2 template), the config output module executes the specified Jinja2 template on the device node data. The resulting string is stored in config/node.name.cfg file.

Would that work for you?

[jbemmel]

Almost: Instead of a Jinja2 template for startup_config, I'd prefer a Boolean flag; if true, aggregation logic would be invoked to generate an initial startup config (based on invoking sub-module Jinja2 templates for specific protocols like bgp, etc. )

The aggregation logic could be specific per device type, although I can come up with a generic OpenConfig flavored one that would work for both sros and srlinux (and maybe others like frr, if I can find the time to add it)

[jbemmel]

Not sure if Ansible would be up to the task of merging; if the sub-modules could stay within Python and produce Python objects ( dicts ) instead of going via Jinja2 text templates, that might be even better

I keep finding myself spending time on how to solve something in Jinja2, and in the sros/srlinux code I have to use Ansible to_json to parse the generated YAML templates

[ipspace]

The challenges I see with using existing configuration logic to generate startup config:

• I don't want to use Ansible for that. It's like shooting a fly with an ice cream sandwich.
• I'm not sure that following the current flow of initial-config.ansible would result in usable startup config -- see my reservations above, I know it would be a dismal failure for IOS, NX-OS and probably EOS, but might work for Junos.
• For devices that use JSON/YAML/XML formatted startup config you have to create a single document, and assembling a bunch of configuration snippets would never work well.

From the programming perspective, I don't want to invest into generic aggregation logic framework until we understand what we're trying to do and are pretty sure it applies to multiple devices (aka: understand the problem first). We should start with having the aggregation logic in a device-level template that would include other templates, and to avoid built-in naming conventions, I prefer having a template name in the settings instead of a boolean flag.

Using a Python module to generate the startup config is intriguing though. How about:

• You can specify startup_config_template or startup_config_module in defaults.devices.type
• The startup_config_module would have to return a dictionary of filename:text pairs.
• We'd have a per-device subdirectory in config directory (similar to current host_vars) that would have a single startup-config.cfg (for startup_config_template) or whatever the config module returned.

More later (assuming you're OK) with this idea.

[jbemmel]

See also https://srlinux-at-your-service.medium.com/pen-networking-thoughts-62994b0385cc

[ipspace]

Looks like there are no takers, and something similar has been implemented in #208. Closing this one.