Export Device Types from NetBox

[bortok]

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

[tardoe]

Use-case: Be able to map between DeviceTypes and Containerlab kinds.
E.g.

• Netbox DeviceType Slug of 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

• Netbox device types MX104, MX204, MX480, MX960 all map to the juniper_vmx kind in Containerlab.

nodes:
       syd1-edge1:
            kind: juniper_vmx <------- actually an MX204 in Netbox, only vMX is emulatable.
            image: vmx:23.1R10 <-------|

[bortok]

Looking into design choices to implement this:

1. Use DeviceType slug directly as 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).
2. Use a custom field in Netbox for type. Discarded, as nrx has to work with vanilla netbox deployments.
3. Create 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.
4. Rely on vendors or clab maintainers to provide up-to-date mappings. This could work for Nokia, but unlikely for others. But since it is only Nokia kinds that leverage type parameter, it might be enough. Checking feasibility of this option.
5. For the rest we could use the option 3, if/when needed.

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.

[tardoe]

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.

[bortok]

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:

• kind
• type
• image
• license
• template (this one is for nrx to pick a proper j2 template)
• and in general, all the other parameters too

My current thinking is that the following from model would take higher precedence:

• type

And for these higher precedence would be from platform:

• kind
• image
• license
• template

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.