Data Model Transformations in Network Automation Solutions
Last year I wrote an article describing data model optimization going from a simple this is what we need to configure individual devices to a highly polished high-level network nodes and links model. Not surprisingly, as Jeremy Schulman was quick to point out, the latter one had Jinja2 templates you wouldn’t want to debug. Ever. You can’t run away from complexity… but you can manage it.
Many successful network automation solutions (example: Cisco NSO) solve the “we’d love to work with high-level data models but hate complex templates” challenge with data transformation: operators work with an abstracted data model describing services, nodes and links, and the device configuration templates use low-level data derived from the abstracted data models through a series of business logic rules or lookups (aka network design).
The multi-level data model approach might look unnecessarily complex until you’re trying to implement a multi-vendor solution, or a solution that could be adapted to multiple network designs. Whenever you have to deal with multiple abstractions (at the top) or multiple target platforms (at the bottom), using a standardized device-/node-level data model that is as close to device configuration as possible is the only way to stay sane.
Sounds too abstract? No worries, here are the details: I extended the original data model optimization article with an overview of data model transformation concepts, and a data transformation example (the source code is on GitHub).
Totally agree - successive transformation is the key to maintaining sanity for large complex configurations.
Keep the complex logic out of templates!
That was the approach we took way back in https://blog.ipspace.net/2013/10/create-network-models-with-cmls.html and distilled in http://sk2.id.au/thesis