platform-specific python augment hooks

[ssasso]

There are some situations where we may want to run python pre/post augment/trasform hooks only for every node of a specific platform (*).

I would try to create a structure similar to the plugins, to be invoked for every node if the specific module exists/for every platform.

example:
if platform/dellos10.py exists, it will be called for every dellos10 node (with "pre_transform" and "post_transform" functions).

This would allow to use python for platform-specific complex tasks/transformations.

Do you think this can be useful?

(*) my very specific use case:
While implementing EVPN Symmetric IRB for Dell OS10, I realized that some brilliant engineer at Dell decided that, if you want to use irb with vxlan, then the interface shall have a different name (virtual-network X instead of vlan X, with a mix-and-match between the twos, and you cannot use anymore the old syntax). This will require some refactor on all the interface names/structures specific for Dell, which IMHO should be done on a python code, rather than on Jinja templates.

Yes, I can do this with a very specific plugin, or with a full refactor of dellos10 vlan module, but I think this can be more generic, also for future use cases.

[jbemmel]

IMHO this is a bad idea, the templates are already device specific and the perfect place to address these types of vendor specific inconsistencies.
If really needed, you could do this renaming in the Dell specific EVPN module as well

[ssasso]

The problem I am facing is that this does not involve "only" the evpn stuff, but it impacts also other modules. And doing some "coding" stuff in Jinja can result in a big mess.

Just to give you an idea.

With "plain" IRB interfaces, I can do:

interface Vlan 100
  ip address 192.168.0.1/24

But, If I want to use EVPN IRB, I cannot assign anymore an IP address to Vlan 100, but I need to do

interface Virtual-network 100
  ip address 192.168.0.1/24
  ...bla bla bla...

interface Vlan 100
  virtual-network 100

As you can see, this is involving the "initial" module, because the interface name where to assing the IRB address is changing.

[jbemmel]

interface {{ 'Virtual-network' if evpn.irb else 'Vlan' }} 100

{% if evpn.irb %}
interface Vlan 100
  virtual-network 100
{% endif %}

IMHO something like this is much easier to read/follow than using pre/post hook functions in separate Python files.
For SR Linux there is vlan related logic in the 'initial' module, not "cleanly" separated but...

[ipspace]

As @jbemmel said, it's a mess. The way the interface creation code is written, the interface names are taken from device defaults, and while it would be doable to have platform modules with pre_transform and post_transform hooks (similar to what we do with providers), you'll be stuck if someone decides to have EPVN on some Dell boxes but not on others. pre_transform hook modifying device defaults is thus off the table.

post_transform hook that would modify interface names based on modules used by a device would be another option, but then you'd have to go through all the potential data structures that contain interface names (example: in-VRF OSPF interfaces). Never-ending nightmare and a source of hard-to-catch bugs as we add new thingies. Also, to make it complete, you'd have to scan all the data structures for all the nodes and fix the neighbor lists.

Finally, the suggestion made by @jbemmel: it would work, but you'd have to be careful to use the same logic every time an interface name is mentioned, probably using a replace function or some such to stay independent of the way interface names are formed. That does sound like a recipe for a cut-and-paste disaster... hopefully not as bad as this one https://www.bugsnag.com/blog/bug-day-ariane-5-disaster.

Also, when configuring routing protocols you don't have the underlying data that was used to create interface name readily available, so using a string replace is the only way to go. Still, the neighbor lists would be off, and if anyone decides to use that data structure for something like LLDP connectivity checks (in physical racks), you'd be in trouble.

It seems to me that the only reasonable way forward is to use the "virtual network" interface everywhere (assuming it works without EVPN) and put a curse on the idiot who made that stupid decision. Can that be done? If not, I'll try to figure out something else.

[ssasso]

I'll definitely try the approach to use virtual-network X for all the VLAN cases (even without EVPN).
(most probably it will be easier than expected)

[ipspace]

Where did the "can I have vlan.id" part of the comment go? I got way larger thingy in my email.

Anyway, yes we can copy VLAN ID into virtual interface if that would help. Not sure why it's not there.

[ssasso]

I updated the comment, removing that section, because I was able to handle it in a different (and simpler) manner.

[ssasso]

I did it for every VLAN, and not for every "interface": https://github.com/ipspace/netsim-tools/pull/352/files#diff-4be5cc985785b7d987a6f65f7d3c99a4f016a298d32be3482df65c8f7d1534e1

[ipspace]

Nice solution ;)

[ipspace]

Device quirks (55daae3) might be a good way to deal with this -- in the Dell OS10 scenario, you might have to rename the interfaces, and hope that nothing will go wrong ;)