Open bortok opened 5 months ago
Use-case: Be able to map between DeviceTypes and Containerlab kinds. E.g.
7220-ixr-d3l
could map to ixrd3l
which is the string needed to represent this type as a Containerlab kind
against the SR-Linux container image.
nodes:
syd1-pd1-sp1:
kind: srl
type: ixrd3l <----------------------------------- type mapped from DeviceType.
image: ghcr.io/nokia/srlinux:latest
juniper_vmx
kind in Containerlab.
nodes:
syd1-edge1:
kind: juniper_vmx <------- actually an MX204 in Netbox, only vMX is emulatable.
image: vmx:23.1R10 <-------|
Looking into design choices to implement this:
type
. Discarded, as there is less types supported by clab
than different Nokia SR-Linux models (that would be a universal statement for most vendors).type
. Discarded, as nrx
has to work with vanilla netbox deployments.model_map.yaml
in templates
repo to map various Device Types from NetBox into types
supported by clab
. This is the last resort option, since it would effectively offload the function to track various models and what they should map to to the end users.type
parameter, it might be enough. Checking feasibility of this option.Kinds that don't use type
(everyone except Nokia at the moment) need to be mapped via kind
and image
. What that implies is a different type/flavor of the operating system, and that information is typically covered by platform
field in Netbox. Nrx already provides mappings for platforms.
I think option 3 makes sense - users have to create some maps anyway for nrx so one more won't be too burdensome, especially if we create some sensible defaults - e.g. anything that looks like junuper-mx.*
--> vMX kind. For this mapping, it would have to be a mapping of Device Type to kind
(required) + image
(required) then an optional type
.
To implement option 3, we need a decision which property, model
or platform
, has higher precedence to map overlapping parameters. For example, both could be used to determine which node image
to use in containerlab. Here is a list of parameters that could be defined by both:
My current thinking is that the following from model
would take higher precedence:
And for these higher precedence would be from platform
:
In other words, when mapping parameters, I plan to first run through platform_map.yaml
, and then through model_map.yaml
by overriding type
but leaving everything else as is if defined. If not defined, then use a value from model_map.yaml
.
Export Device Types from NetBox and map them to Containerlab node types. This would allow to emulate different device models of the same platform. On Containerlab side this is supported by SR Linux