Multiple Templates per router

[jjavierweb]

Environment

• Python version:
• Peering Manager version:

Proposed Functionality

It would be nice if we could assign multiple templates to routers, and at the time of deployment all templates would be fusion on a single configuration, this would allow creating independent templates for route-maps or prefix-list while also providing all the regular neighbors and such

Use Case

performing a large configuration where multiple AS numbers require specific route-maps or prefix-lists, a template for each is created, and then all templates are rendered into a single configuration for deployment

External Dependencies

[mngan]

Could you clarify what you mean "a template for each"? Each AS? I think I know what you mean, but just want to make sure I understand.

There have been some suggestions to use configuration contexts. It is possible that such a thing could contain this information per ASN (or per object type). So you don't necessarily need to use a separate template for this information. It sounds like you just want a place to store this static information that will get included into the templates.

[rlanyi]

I have a similar use case for this: I don't want to push very-very long prefix-lists to a router every time when I create a peering session. If I could have one template for BGP sessions and another for prefix-lists then I could apply them with different frequency. (E.g. by creating multiple cron jobs for each configuration templates.)

So besides the behaviour that @jjavierweb mentioned above where multiple assigned configurations would be merged for a specific router, it would be nice to have the possibility to generate configuration with one selected configuration template for that router as well.

[jjavierweb]

@mngan I mean for example I want to have a template for creating prefix lists, another template for creating route-maps and another template for creating community lists
that what I meant by a template for each is created, rather than a template for AS

[nido009]

another idea would be to add the ability to link policies to and communities to routers and enhance policies with it's own set of templates to push policies to routers instead of heaving to put them into the general template and adding them in dhe policies section.

[jamesditrapani]

I think @nido009 has probably hit the nail on the head here, sounds like the best way to do it. I'll take a look into what the options are

[falz]

While I gave the obligatory thumbs up and the suggestion that @nido009 made does seem quite logical, it could also be limiting.

Expanding this further, perhaps instead of having a 1:1 jinja template for a 'thing', perhaps consider implementing it as 1:many. This could fit either scenario - if it stays device-centric, one could have however many templates as you want (although I'm unsure how they all merge together, if they do at all)

This could apply to the template-per-thing idea as well - policies, communities, peers.

However, this strays away from the original suggestion which is specific to prefix-lists - what would those link to? There's nothing prefix-list-ey inside Peering Manager currently, and it seems like that's the thing with most churn, so why bother updating all static policies that refer to prefix lists when one can just update only the prefix lists.

[gmazoyer]

Another thing we want to look at, is adding a function, to the templating system, to include a template into another one. So one might create a bunch of templates, then another one which includes the previous ones in the order the user wants.

The final template would look like:

{% include "bgp-sessions" %}
{% include "bgp-policies" %}
{% include "prefix-lists" %}
...

[wtremmel]

This is a great idea! Would make templating and re-using template parts way easier. Of course what’s also needed then is a kind of testing function to see how the output of a template part looks like (in a browser or text file).

…

On 22. May 2022, at 13:33 , Guillaume Mazoyer ***@***.***> wrote: Another thing we want to look at, is adding a function, to the templating system, to include a template into another one. So one might create a bunch of templates, then another one which includes the previous ones in the order the user wants.

[falz]

This would make sense, especially if the templates can be named arbitrarily and referred to arbitrarily, that way anyone could get as granular as they want with includes.

[gmazoyer]

Inclusion tags added in 9ce109d