One of the harder things to do when it comes to network automation is work with the majority of the install base that exists out there. This is true even if we focus purely on data extraction, i.e. issuing show commands and getting the results in an automated fashion. The reason for this is that most devices do not support returning structured data in formats such as JSON or XML, and this often times makes automation a non-starter for network engineers.
0 Comments
Over the past several months, I’ve found myself holding back on writing posts simply because my blog platform does not support the ability to embed code or even change fonts to resemble code, CLI, or working on a terminal. Screen shots are good, but offering the ability to copy and paste is nice, plus it just looks cleaner. This is unacceptable.
Over the past few years, I’ve written quite a bit about SDN and more recently more about what can be done today with existing products, APIs, and tools in terms of improving operational efficiencies. Most of the examples have leveraged modern network devices that have some type of API because it streamlines how to integrate with 3rd party systems be it a custom application or a platform like Ansible (a platform that I’ve written about frequently). I’ve posted examples here and there on GitHub on these topics, but nothing that starts from the ground up.
If you have ever worked with Ansible, it’s almost a guarantee that you have used their online docs to figure out what parameters a given module supports, how they should be used, or what their defaults are. Over the past few weeks, I’ve been working on a few custom modules and was trying to find a way to generate web docs for them, and have them locally accessible or easily posted to GitHub.
|
AuthorJason Edelman, Founder & CTO of Network to Code. Categories
All
Archives
May 2015
|