Extending Config Contexts #505
Replies: 4 comments 4 replies
-
I think adding Config Contexts to a variety of objects is really important, especially in the absence of a "custom fields" module like e.g. NetBox. For example, there are a bunch of "BGP peer parameters" which have no place in Peering Manager currently — and I am sure there will be other vendor-specific things which could be storeed in Config Contexts:
Some of these it might make sense to have their own dedicated UI fields and values (e.g. |
Beta Was this translation helpful? Give feedback.
-
tl;drFollowing discussion about adding default-originate — where using tags was suggested — and config contexts, perhaps the "kitchen sink" should be the Tag model? Consider the concept of "originating a default route" is fairly simple, but implemented in different ways by different vendors:
In other words, lots of NOS vendors give engineers a way to originate a default route as a special case. And engineers will treat their favourite NOS' implementation of BGP as the canonical way to do BGP (I shall call this "vendorthink", something I'm guilty of too!). Another "vendorthink" that can trip up users: several BGP configuration implementations do not allow multiple import/export policies for a peer or group (e.g. anything with a Cisco-like syntax, but also FRR, VyOS, EdgeOS, RouterOS, etc). If I'm an engineer it might seem impossible to me how to implement a list of multiple routing policies as per Peering Manager. We should signpost how PM's Cisco-mindset users can make a per-peer route-map that will We should suggest some good practices for how users can build their policies in PM and how to make good templates. For example, I don't like having special cases where the names of things (e.g. name of export policy) confers magical properties (e.g. originate a default route). I think that can create fragile systems, where config and code are intermingled. So instead of templating checking if e.g. the name of a particular policy is in the export policies for a peer, we should encourage the use of
This effectively makes the
What if we consider the Tag model as that per-object generic "config context"? That would leave lots of flexibility for engineers to define whatever they like. For example, they could define tag Of course this leaves the possibility of tagging an IX with a tag which is intended for direct and IX BGP sessions. But that's no different to putting values in a routing policy's config_context which are not used by templates, so we don't lose anything. CaveatsRouting policies are an ordered list. Tags are an unordered set. Imagine these two hypothetical tags were applied to the same peer:
How does a template writer know what to do with the union of two config contexts? Maybe the answer is to give the template-writer some "merge contexts" filters so they can decide. Salt-style mergingLists concatenate, dicts merge. Therefore hold180 + keepalive60 =
Netbox-style mergingLast one wins, so we need ways to sort to define "last". Therefore hold180 + keepalive60 =
Raise an exceptionEnforce namespacing. Therefore hold180 + keepalive60 = "ERROR: 'timers' defined in tag 'hold180' cannot be redefined in 'keepalive60'" How to use Tag config contexts?(these are draft proposals, not real examples of actual template code) {% set tag_context = peer.tags|sort(attribute="slug")|merge_contexts_like_salt %}
neighbor {{ peer.address }} timers {{ tag_context.timers.keepalive or 10 }} {{ tag_context.timers.hold or 31 }}
/routing bgp peer add \
{% if tag_context.passive %}passive=yes{% endif %} \
remote-address={{ peer.address }}
{% if tag_context.override_local_as %}set protocols bgp {{ local_asn }} neighbor {{ peer.address }} local-as {{ tag_context.override_local_as }}{% endif %} Other Questions
|
Beta Was this translation helpful? Give feedback.
-
I can see uses of the Netbox-style scoping of config contexts. Netbox targets devices via various criteria. I can kind of see you wanting to target not just BGP Sessions, but perhaps BGP Groups/Internet Exchanges and Routers. So it could be a little different in that respect, but there is definitely a use case for the Netbox-style scoping. You may want BGP groups with specific tags or specific naming patterns to get one config context vs another. This avoids copy-pasta amongst a lot of similar BGP groups. You would will want to keep per object config contexts, but you would only use them in specific cases. In my case, I have some BGP sessions that need individual fine tuning. I haven't looked at how the config contexts work right now. I am guessing these are just available on the supported object types and there is no inheritance model at all. That would seem fine, if we could use the Netbox-style scoping to apply additional config contexts to objects. I am a little wary of the merge model. Netbox's merge model is very simple. It simply merges dicts at the top level rather than doing a nested merge, which is what Salt does, and more... For the simple merge, you really can't have complicated nested structures that you might want to deeply merge. It is only really good for adding new keys or completely overriding existing ones. The deep merge that Salt does usually works the way you want it to, except when it comes to lists. Sometimes you want it to overwrite, some times append. Salt will append by default, and it has a bunch of special keys to indicate how two dicts should be merged. So, I guess you could just provide the user with all the different contexts, and then let them merge the contexts via filters to suit their needs. As an aside, you could also leverage config contexts (or graphql query) from Netbox/Nautobot as well for the device. That could be another context that lives along side the Peering Manager ones if you have enabled Netbox integration. Some people might find that useful, but is really a separate thing from what we are talking about here. |
Beta Was this translation helpful? Give feedback.
-
Implementation in progress #596 |
Beta Was this translation helpful? Give feedback.
-
Opening a discussion around the best way to extend Config Contexts to further objects.
At the moment only routing policies and router objects support config contexts where custom and adhoc data can be defined via JSON. Going forward we need to look at extending this to further objects or launching an inheritence system allowing users to define further adhoc info to different models.
The easiest way to do this currently is to simply bring Config Contexts to existing models such as IXP, IXP Session, BGP Group, Direct Session, ASN, etc. All of these objects are either exposed directly, or indirectly to the templating engine and can be accessed this way.
The other option drawn out by @gmazoyer is to define a multi stage config context where data can be defined per object type (e.g. all IXP models) and a config context for specific models (e.g. a single IXP), these would then be merged into the templating engine with with per model data taking presedence over per model type.
How are people currently using config contexts and what is going to ensure you benefit from them going forward? Do you currently have a road block when templating due to the current lack of config context support? Or do you simply have another idea how we can do this better? Drop a message below! 😃
Beta Was this translation helpful? Give feedback.
All reactions