How to handle different Juniper products with less effort but keeping the consistency

[ssasso]

(following from #662 )

Right now, the only official supported product from the Juniper family is the vSRX.
It is correctly defined on the topology-defaults file, and the different templates are referred to it.

However, if we want to add the official support for additional Juniper products (starting from vMX, but in the future also vQFX), we need to consider that:

• most of the configuration templates will be the same
• some minor changes are required for some features (i.e. the first one that comes to my mind is the different way of handling EVPN/VXLAN between MX and QFX)
• interface names may differ.

My proposal is to:

1. every supported platform (vSRX, vMX, ...) needs to have the appropriate entry in topology-defaults
2. the current ansible templates are already named as generic "junos"
3. for the features where the configuration is different we should allow to include different additional files based on the platform (add on topology-defaults a group_var called junos_platform that can be used inside the templates? or expose directly the netlab platform in a host_var?

[ssasso]

Additionally, since the "common features" are handled on the "junos" templates, how shall this be documented?

[ipspace]

Obviously you need a different device type, and maybe this is a good time to add "merge_from" functionality so you don't have to repeat all of the stuff but just merge vSRX data into vMX data (I would do the "merge_from" part if you like the idea).

Next, the configuration templates. Obviously you could handle them the way we handle Linux distros, or we could change the way we find device templates in Ansible playbooks (probably this would be better, and would also solve VLANs on IOS XE if I ever decide to implement them).

We have two variables to play with (at the moment): netlab_device_type and ansible_network_os. We could also throw device into the mix.

Today we select deployment task lists based on netlab_device_type|default(ansible_network_os) (use ansible_network_os if netlab_device_type is not defined). We could either keep that or expand the list of potential file names in include_tasks calls to check one and then the other if you feel we need that, but I don't think configuration deployment on vMX would be different from vSRX.

Next, the configuration templates. Today we select them based on:

    with_first_found:
    - "templates/{{ config_module }}/{{ netlab_device_type }}.j2"
    - "templates/missing.j2"

... where netlab_device_type is calculated as above. We could easily change that to:

    with_first_found:
    - "templates/{{ config_module }}/{{ device }}.j2"
    - "templates/{{ config_module }}/{{ netlab_device_type }}.j2"
    - "templates/missing.j2"

... so you could have vmx.j2 for the device-specific configurations and junos.j2 for works on every Junos platform configuration. Likewise, I could do this change if the idea works for you, or you could do it as part of the vMX PR (just make sure you find all instances of that monstrosity).

Finally, don't worry about interface names. There's a reason we're using x.ifname in the templates: interface names are created in the link transformation code and used as-is in the templates ;)

[ssasso]

... where netlab_device_type is calculated as above. We could easily change that to:

    with_first_found:
    - "templates/{{ config_module }}/{{ device }}.j2"
    - "templates/{{ config_module }}/{{ netlab_device_type }}.j2"
    - "templates/missing.j2"

device right now is not defined as ansible var, I can add it somewhere as group_var for every specific device group.

[ssasso]

Even better,

netlab/netsim/outputs/ansible.py

Line 31 in aac8a03

topo_to_host_skip = [ 'name','device' ]

I can remove device from the "cleaning"

[ipspace]

Looks like we're about to add another variable just because the previous attempt was badly thought out. Nobody uses netlab_device_type yet (apart from routeros7), so maybe we could just implement two levels of lookups (using netlab_device_type and ansible_network_os).

IIRC I wanted to have netlab_device_type instead of device to indicate it's an internal netlab variable (or some such), but I'm OK with going with one or the other as long as we don't get to a point where we have a half-dozen ways of doing the same thing ;)

[ssasso]

Ok, clear.
NP will try to change the draft PR for using these two levels

[ssasso]

@ipspace I think I correctly addressed everything about the usage of netlab_device_type and ansible_network_os in #670 .
I did multiple tests with my env (also creating a "fake" custom template for bgp to verify its precedence), but please have a look at it as well.

[ipspace]

Implemented in release 1.4.2