Building device structured data from smaller services

[gusmb]

I was recently thinking about how to make the DC network more consumable. The config replace approach requires a network team to own and manage the full intended state data. However, other services or workflows might need to request things like a static route or a routing policy to be implemented on the fabric.

With this in mind, what if we had a bunch of small services that expose certain parts of the configuration and makes them consumable via APIs. Following this example, there could be a static route or route map as a service API, that would generate and maintain device structured data conforming to the AVD schema.

It would be nice to have an easy way to collect all structured data coming from the different services, and merge it together on schema keys, in a similar way that it's done in yaml_templates-to_facts. One thing to consider is conflicting config by different service instances, like 2 load extranet service instances requesting the same static route in the same device but with a different next hop, or the same route map with different content.

The result of building the fabric is the same, the structured data for the device full configuration, however the input is not centrally managed, but it comes from a bunch of smaller services that own and publish structured data.

Does pyAVD have functions exposed to merge instances of structured data, preview and visualize or fail on structured data merge conflicts?

[ClausHolbechArista]

Very interesting use case.

You could use custom_structure_configuration_prefix to contribute overlapping data, which would then be merged according to the schema. We do not have any exposed functions to block merge on conflicts, when you use structured config.

With eos_designs we do handle conflicting data inputs in most places, by using a utility called "append_if_not_duplicate" which can either raise or ignore. It checks uniqueness on "primary_key" or any other number of fields, and can also ignore certain fields.

Unless you use eos_designs, you would have to build your own tool to merge these external snips and handle conflicts. The utils in (Py)AVD are not considered part of the stable API, so if you use them, just be aware they are subject to change. You can find them under pyavd.vendor.utils but we are working on moving them to pyavd.utils (may happen in a minor release).