Config template support 🚀

[kellerza]

383 triggered some good discussions on config template support

Scope of #383

• [x] basic template support (labels)
  • [x] label to config var translation, so config: vars: will just be infrastructure work
• [x] chainable template support
  • [x] add templates & test
• [x] Transport interface with SSH implementation
  • [x] kind vr-sros
  • [x] kind srl
• [x] Template functions: documented here
  • [x] split, join, slice, index --> slice &index, len are standard, but the value for slice&index are not last (for | chaining) so reimplemented them
  • [x] ip, ipmask (can probably be done using {{ split .ip "/" | index 0/1 }})
  • [x] contains, require
  • [x] default with type checking, likely only "int" usable
  • [x] expect & optional for "yang-lite" with regex support
  • They have exactly the same usage, and NO OUTPUT. The only difference is that the one might be omitted (and default used later)
  • supports: ip, int, str, 1-10 (range of int), \\d+ (any regex)

Other work:

• [ ] New config: vars: instead of labels: @kellerza
• [ ] Transport implementation for gNMI @hellt
• [ ] yaml templates for gNMI @hellt

Future evolution

• [ ] Improve SSH transport prompt parsing
• [ ] Static YANG validation of templates
• [ ] MD-CLI to yaml conversion
• [ ] more template functions & tests
• [ ] more templates

New config vars

Node

nodes: xx: or defaults:
    config:
      vars:
        isis_id: 0
      transport: ssh
      templates:
        - ports
        - ifaces
links:
  - endpoints: [sr1:eth1, sr2:eth1]
     vars:
      port: 1/1/c1/1, 1/1/c2/1

Params

$ ./clab config --help
configure a lab based using templates and variables from the topology definition file
reference: https://containerlab.srlinux.dev/cmd/config/

Usage:
  containerlab config [flags]

Aliases:
  config, conf

Flags:
  -c, --check int               render dry-run & print n lines of config
  -h, --help                    help for config
  -l, --template-list strings   comma separated list of template names to render
  -p, --template-path strings   comma separated list of paths to search for templates

[LimeHat]

Have you considered decoupling of base topology definition ("old" clab.yml format) from new variable definitions?

[hellt]

Hi @LimeHat if you mean to keep variables used for config generation apart from the topology file, then we had a few rounds of discussions about it and the majority of responders were find it more comfortable to have the variables defined in the same file as the topology. This has some benefits such as:

• single file for a lab. Makes it easier to distribute/write
• visual guidance on which variables applied to which node
• no duplication of lab structure as we are reusing the topology structure

The cost is that the file might be bigger than one would want.

I guess a compromise can be added to "Future evolution" is to have a something like this

config:
  transport: ...
  vars-from-file: <filepath>

to indicate that variables should come from the file

[kellerza]

Move discussion to #487