Post 3: Green Monster Plugin system

Part 3 of N.  See Part 2 or Part 1

Green Monster Plugin design

One of Green Monster’s primary goals was to provide a framework to automate tasks against Network Switches, KVM Switches, Rack PDUs, Blade Chassis Management Interfaces, iLO/DRAC.  By abstracting the network design and underling hardware my team members do not need to know how all the network switches interconnect or how to use the CLI/GUI for each manufacture/model.

I created a plugin framework where each model references a DLL file that is to be loaded when action against it is to be taken.  This Plugin Name field (see Green Monster Database design post) exists on the Model level and the asset attribute level.  This allows for a specific (maybe version specific) dll to be used on a single asset or a version agnostic DLL to be used on all common models.

When a device action is being performed Green Monster will run the get plugin sproc that first checks to see if the “asset” as a custom plugin.  If not it looks up the plugin for the model.  This seemed to work well when a single device had a different version of software (say Switch firmware) that broke with the Model default plugin.  It also allowed a way to prototype a plugin without rolling it out to all devices.

The plugin system allowed for 3 “device types” that I could automate.  KVM Switch, Network Switch and Power Distribution unit (PDU).  I created an interface for each that the plugin had to implement to work with Green Monster. 

I will mostly focus on the network devices because they were one of the main goals with Green Monster. 

 

SNMP was the most used protocol when working with devices.  Though there is nothing in the system that required it to be.  I wrote a power plugin for the HB C-7000 blade chassis OA that utilized scripted telnet.  While it was slow it worked well where the manufactures had lacking APIs/interfaces for automating their devices.