OT - A quick post on using gpg to manage github in Linux

After being used to OSX Keychains in my old mac, I wanted a similar functionality on my Linux laptop. Being prompted each time to login, while interacting with github for instance was annoying. Searching the web, led me to git-credential-store. I was not too happy with the fact that credentials would be stored in clear text, locally, indefinitely. I came across this stackoverflow post that I adapted for Linux. The concept is as follows:

1. Use a .netrc file to store your credentials. This follows the file format for netrc
2. Encrypt this file, using GNU Privacy Guard

Test Driven Development (TDD) for networks, using Ansible

In it’s most basic form, TDD works as follows:

1. Envision the outcome of what you are developing [ Adding a VLAN
   to a switch ]
2. Write a test to validate that outcome [ Is the desired VLAN on
   the switch ]
3. Run the playbook, to invoke the test [ it will fail - RED test
   ]
4. Refactor your code [ write the roles/tasks needed for the tests
   to pass ]
5. Re-run tests [role] to ensure that they now pass

In this post, I hope to share my observations on how I used ansible to implement this using roles. I start with known facts/assumptions:

Of state, idempotency, and CI/CD in the brownfield network

This post is a consequence of an interesting conversation around declarative control systems with a colleague. Throughout the conversation, we kept coming back to the ‘popularity’ of automation and specifically, how revolutionary, it appears for legacy, closed systems(aka 80% of network gear in enterprises). When you think about it, in a traditional control system (a bread toaster, in it’s simplest form), we interact with the system as follows:

1. We tell it (declare) what our desired outcome is (how brown do you
want your toast)
2. Inputs (the slices of bread)

The system then figures out how to achieve your end state. In other words..

The need for a stateful variable tracker and an implementation example

When it comes to automation role models, network engineers have often looked up, to our compute brethren. For decades, compute admins have had tools that allowed them to execute scripts on systems at particular times: typically backups, rsync etc. More recently, in the VM universe, DevOps tools like Chef/Puppet/ Ansible, have empowered ‘Developer Administrators’, to stand up the entire app stack, automatically.

In my network automation journey, I realized early on that, a big gap/obstacle for network automation is the need for a backend, to track positive integers; a source of truth, that knows what numeric value was last

Running ansible at scale

Last week I deployed my first “at scale” playbook. The overall objective was simple: Add new dhcp helper address to about 400 switches. Like most things though, the devil is in the details. Right off the bat, I ran into “non-ansible” related issues (tacacs/ssh). That brought the number of devices to about 270. Not a big number right? At the most basic level, yes, if I was simply pushing configs using the ios_config module. ##Breakdown of the playbook

1. Execute a show run on the device and compile a local backup for each device
2. Run a pre-flight report, specific to the interfaces we are going to impact (multiple ssh sessions per host)
3. Build the configs locally
4. Deploy the configs
5. Validate the configs/Unit testing