Configuration Snippet Concept

[BaptisteGi]

The use case

In certain scenarios, certain aspects of a device's configuration can be quite chaotic. One example that comes to mind is 'static routing':

router static
 address-family ipv4 unicast
  192.168.0.0/24 Bundle-Ether14.1212 192.168.0.1 description Something
  192.168.1.0/24 192.168.1.4 description Something_else
  192.0.2.255/32 Null0 permanent description BLACKHOLE
  ...
 !
 address-family ipv6 unicast
  2001:db8:ffff:ffff:ffff:ffff:ffff:ffff/128 Null0 permanent description BLACKHOLE
  2a01:db8:0:0:0:0:0:0/120 Bundle-Ether14.1212 240 description Something
  ...
!
 vrf management
  address-family ipv4 unicast
   0.0.0.0/0 10.10.10.10
  !
 !
!

It must be possible to capture that data in an object (e.g. "route statement"), create relationships toward IPs / interfaces, then adjust templates (e.g. jinja) to handle data and all flavours of statements... overall I'm not sure it is worth it, especially early in an automation project.

The idea

Basically the idea revolves around storing actual snippets of configuration and linking them to some entities.

The "Snippet" node could have tag/type field in order to differentiate multiple snippets linked to the same device for instance.
Also it could be great to leverage Infrahub Git integration to store those snippets in a dedicated repository.

Here is an example of the data we might pull from the API:

{
  "data": {
    "hostname": "rb01",
    "snippets": [
      {
        "type": "static-router",
        "snippet-content": "...some static configuration ..."
      },
      {
        "type": "bgp-router",
        "snippet-content": "...some BGP configuration ..."
      },
      {
        "type": "something-else",
        "snippet-content": "...something else ..."
      }
    ]
  }
}

Finally, assuming we are using Jinja2 to generate configuration, we need to handle that feature:

some configuration ...
!
!
{% if data["snippets"] is defined %}
{% if "router-static" in data["snippets"] | map(attribute="type") %}
{{ data["snippets"] | selectattr("type", "equalto", "router-static") | map(attribute="snippet-content") | first() }}
{% endif %}
{% endif %}
!
!
some configuration ...

Here it's still very theorical and a lot of complexity is hidden behind the "snippet-content" attribute I believe (how to turn an entire file into a string, how to deal with formating ...).

Example

As a network engineer I need to add a static route to one core router, assuming the above setup is in place, the workflow might be as following:

• Create a branch on Infrahub
• Adjust snippet's content in Git
• Push changes
• Get my changes approved and merged
• Somehow the configuration is generated and applied on the network

Conclusion

To some extend this feature goes a bit against the single source of truth / proper data model approach. It might be confusing for users if they put stuff in the database which is ignored and replaced down the line by a static chunk of configuration. Also all the data stored in this way can't really be used in a different context (e.g. reporting, api integration ...).

As I mentioned earlier I believe this might be interesting in a brownfield scenario, where it would speed up automation adoption. Beyond that it brings agility in the process of automating network configuration by allowing users to create "mvp template" and iterate on it. I guess it's also possible to use the same concept for other purposes (e.g. funky provider interface, bgp router ...).

If we push the concept to the limit (don't know how relevant it is tho) we could break down existing configuration into snippets and setup the whole automation pipeline based on that (create the equipment in the system, attach all snippets to it, define a very basic template and consume generated configuration). Then with this pipeline in place we could iterate and step by step support more and more parts of the configuration (e.g. we shape data model for BGP router, add the data in, develop the template, fall back on the same pipeline and move on to the next part).

[BRBCoffeeDebuff]

I just want to quickly follow up on this. We have seen this and are thinking through ways we might do this. If others have ideas that would expand on this thought please chime in. For now we are going to track this as an Idea for our roadmap.