The purpose of extending module attributes in a user topology

[jbemmel]

Reading https://github.com/ipspace/netsim-tools/blob/master/docs/extend-attributes.md#extending-module-attributes, I'm wondering what could be the purpose?

The module wouldn't use such attributes in its templates, as it is not aware of them (if not, it should have declared them as attributes to start with)

I could see the point of moving this declaration into each module's code, as opposed to the global defaults ( i.e. define the attributes at the point of usage ). The extension mechanism makes sense to me, just not the specific use case here

[ipspace]

Have to write a series of blog posts on the topic, here are just a few ideas. Please keep in mind that:

• I'm putting myself into the shoes of someone who'd like to add functionality to netsim-tools without modifying the global settings or package source (which would be required when adjusting existing modules).
• Modifying existing modules requires a fork and associated headaches until your code is merged upstream. People might have personal or legal reservations about that, and we might not want to make the core code too complex to cater to every whim out there.
• People adding random functionality to existing modules that is only implemented on a single platform (they're interested in) results in balkanization.
• I'm trying to retain keyword checking as much as possible to catch hard-to-spot errors.

OK, here we go:

• Add new functionality like MPLS/LDP. Needs global configuration settings, but it's not a module yet, so we need a mechanism to extend top-level attributes as well as link- and node attributes. Tangential note: node attributes are not checked yet.
• Add new nerd knob to an existing protocol like bgp.anycast or bgp.add_path. I don't want to see netsim-tools exploding into another humongous pile of nerd knobs like a typical NOS, so we need a standard way of adding extensions. Plugins are pretty close, and I have to fix a few search paths to search for plugins or config templates in multiple places, but we still need a mechanism to extend module attributes because adding add_path to bgp makes more sense than a top-level bgp_add_path attribute.

Hope this makes sense,
Ivan

[jbemmel]

I see, in other words you're trying to build modular modules.

I guess in my mind I'm wondering where the recursion will stop. To an extent it seems to me you are solving certain problems for which standard solutions exist (like YANG models with 'augment') - no offense of course

[ipspace]

What I'm aiming for is a simple and stable core that is reasonably easy to implement on new devices plus the ability to extend it.

Obviously we could use a YANG data model to describe the lab topology data model, but I'm guessing that it's still easier for most people to add a YAML list saying "add these keywords to a module" than to create an augmented YAML data model.

Anyway, the whole extensibility framework is much more than just adding attributes to a data model -- you need topology-to-device data transformation and then node-to-configuration transformation (regardless of whether the configuration is YANG-controlled or a text file).

[jbemmel]

Checkout what Roman built for Containerlab: https://json-schema.app/view/%23?url=https%3A%2F%2Fraw.githubusercontent.com%2Fsrl-labs%2Fcontainerlab%2Fmain%2Fschemas%2Fclab.schema.json

…

On Thu, Dec 23, 2021 at 7:28 AM Ivan Pepelnjak ***@***.***> wrote: What I'm aiming for is a simple and stable core that is reasonably easy to implement on new devices plus the ability to extend it. Obviously we could use a YANG data model to describe the lab topology data model, but I'm guessing that it's still easier for most people to add a YAML list saying "add these keywords to a module" than to create an augmented YAML data model. Anyway, the whole extensibility framework is much more than just adding attributes to a data model -- you need topology-to-device data transformation and then node-to-configuration transformation (regardless of whether the configuration is YANG-controlled or a text file). — Reply to this email directly, view it on GitHub <#82 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPQAC6VDJDO6WDA6HG2CYTUSMPXTANCNFSM5KQUR6KQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[ipspace]

Checkout what Roman built for Containerlab: https://json-schema.app/view/%23?url=https%3A%2F%2Fraw.githubusercontent.com%2Fsrl-labs%2Fcontainerlab%2Fmain%2Fschemas%2Fclab.schema.json I use JSON schema in all sorts of places, so I know exactly how tedious it is ;) Here’s a simple example: https://www.ipspace.net/kb/DataModels/70-Validation.html It’s nice to know there’s an online app to work with JSON schemas. Thanks for the pointer. Best, Ivan

On Thu, Dec 23, 2021 at 7:28 AM Ivan Pepelnjak ***@***.***> wrote: What I'm aiming for is a simple and stable core that is reasonably easy to implement on new devices plus the ability to extend it. Obviously we could use a YANG data model to describe the lab topology data model, but I'm guessing that it's still easier for most people to add a YAML list saying "add these keywords to a module" than to create an augmented YAML data model. Anyway, the whole extensibility framework is much more than just adding attributes to a data model -- you need topology-to-device data transformation and then node-to-configuration transformation (regardless of whether the configuration is YANG-controlled or a text file). — Reply to this email directly, view it on GitHub <#82 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPQAC6VDJDO6WDA6HG2CYTUSMPXTANCNFSM5KQUR6KQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.  You are receiving this because you commented.

[ipspace]

netlab got attribute validation in 1.5.0