Conversation
| @@ -0,0 +1,38 @@ | |||
| query device_startup_info ($device: String!, $bgp_group: String) { | |||
There was a problem hiding this comment.
Require device but allow the filtering of a group to be optional
| {% endfor %} | ||
| {% endif %} | ||
| {% endfor %} | ||
| {% set device_interfaces = data.InfraDevice.edges[0].node.interfaces.edges %} |
There was a problem hiding this comment.
Previously we had a section that set the loopback and management interface at the top of the startup config template. There we'd iterate over data.InfraDevice.edges[0].node.interfaces.edges as we now have another template where we don't query for InfraDevice but instead for InfraInterface we need to manage these different scenarios. For this reason we set the device_interfaces variable within the main template and use a conditional statement in the imported device_startup_interfaces.j2 for the alternative.
| {% endif %} | ||
|
|
||
| {% set ns = namespace(loopback_intf_name=none, loopback_ip=none, management_intf_name=none, management_ip=none) %} | ||
| {% for intf in device_interfaces %} |
There was a problem hiding this comment.
The only difference when this file is moved is that we iterate over device_interfaces instead of data.InfraDevice.edges[0].node.interfaces.edges
1 participant
This PR provides an example of how you would be able to have nested transforms for Jinja where a main template includes information of a sub template but it's possible to run the same subtemplates in isolation.
Using the
device_startuptransform I've added two sub transforms below it.device_startup_bgpas well asdevice_startup_interfaceseach of these new templates could be executed in isolation.Some examples of commands that expect that the base models and example data from the Infrahub repo are loaded:
This command works exactly as before:
The BGP template
In order to generate the BGP config we can run this sub template within isolation
❯ infrahubctl render device_startup_bgp device=atl1-edge1 router bgp 64496 router-id neighbor IX_DEFAULT peer group neighbor IX_DEFAULT local-as 64496 neighbor POP_GLOBAL peer group neighbor POP_GLOBAL local-as 64496 neighbor POP_INTERNAL peer group neighbor POP_INTERNAL local-as 64496 neighbor POP_INTERNAL remote-as 64496 neighbor UPSTREAM_ARELION peer group neighbor UPSTREAM_ARELION local-as 64496 neighbor UPSTREAM_ARELION remote-as 1299 neighbor UPSTREAM_DEFAULT peer group neighbor UPSTREAM_DEFAULT local-as 64496 !Alternatively with additional filters on the peer group:
❯ infrahubctl render device_startup_bgp device=atl1-edge1 bgp_group=POP_INTERNAL router bgp 64496 router-id neighbor POP_INTERNAL peer group neighbor POP_INTERNAL local-as 64496 neighbor POP_INTERNAL remote-as 64496 !The one for interfaces works in the same way:
Or when we provide a filter for the interface name:
Note The loopback and management interfaces come back as
Nonehere (as they weren't identified). It would be trivial to fix this within the template but left it here to highlight the need to apply some additional logic when using this approach as there might be variations with regards to how these templates would behave depending on how they are executed.The GraphQL query tied to the BGP config is a sub section of the regular query where as the query for the interfaces differs from the original one. It would still be required that they request the same information.
In all of these examples I've used a device as the key. It would be possible to run the interfaces query without specifying a device but it would also provide output for all devices on the system if that happened (also the variables to set loopback and management would be incorrect as each device would override the variable for the previous one.
Given that artifacts themselves would be tied to a single starting point (the member of a target group). I don't know if it's relevant at this stage to look at providing entrypoints outside of the device in this case, but there might be examples that I haven't thought about yet.