Zenoss: The Straw That Broke...The YAMLs Back

I remember when my buddy over at Linux Dynasty first introduced me to Zenoss 1.x a few years back.  At the time, I knew nothing about python or any of the related open source projects related to python.  I only knew that I was not a fan of Zope only because it had caused me a lot of grief at a previous job.  After looking at it for a few minutes, I had decided that the reporting aspect was severely lacking, so I spent a week hacking up some python and TAL code in order to create what I had called zenoss-organized-graphs, a few dynamic reporting template that allowed you to select what to graph from standard combo dropdowns.  My employer decided not to use Zenoss, and when Zenoss launched 2.0, the whole backend (including the reporting engine) had changed completely, and my one-week-hack project died right then and there.  Fast forward to last year when, right before I started my new position, the Operations VP had already decided and purchased Zenoss Enterprise 2.5.x.  Thus began my reignited love/hate relationship with Zenoss.

Originally, because of the nature of the hosting provider, we had to run Zenoss using purely SSH/Nagios commands and scripts.  The performance and overhead of all those SSH connections, despite our attempts to keep all the scripts short and zippy, was a headache.  One day, while trying to update the default behavior of a the Solaris Device SSH templates, I discovered that deleting ZenPacks is BAD.  So bad that the only way to recover from the situation it caused was a ZODB Restore.  Mind you, this was not the first issue I had regarding ZenPacks, but it was the straw that broke the camel's back.  I made a solemn vow to myself that I would avoid ZenPacks as much as possible.

Let me clarify that last statement just a bit.  I believe that ZenPacks have a useful purpose, as I do install the Core and Enterprise ZenPacks.  That purpose is to add tabs/menu views, like the Zeus ZenPack, or to add global functionality, like LDAP-Authentication or the Holts-Winter Prediction.  But due to what I consider its volatile nature (of removal/undo), I simply do not think it is the best way to perform simple updates to templates, reports, devices, etc.  Again Linux Dynasty, a much more devout follower of Zenoss than I, had a solution --- probably based loosely on our earlier carefree Zenoss 1.x python discussions --- and it came in the form of the Zenoss_Template_Manager.  I am certain that it is a great tool, and if you have been using it and you love it, then read no further.  However, even though I am a big fan of getopts and passing parameters to a script, the prospect of having to pass multiple DataSources, Thresholds and GraphDefs did not readily appeal to me.  I needed a way to manipulate the fairly complex templates I had built using configuration files, which also serve (for me, at least) as a better backup technique than the ZenPack or the ZenBackup.   Zenoss itself uses XML to import changes into the ZODB but, while I believe in the power of XML, there had to be a better way for humans to process the data quickly and easily enough to affect rapid changes for template duplication, etc.  And thus began my conversion to the YAML religion.

Originally, I wrote my zenossYAMLTool to be for adding and removing devices and templates.  Throughout the course of the year, I would extend it to cover alerts, devices, event commands, event mappings, os processes, reports, templates, transforms, users/groups and maintenance windows.  As I needed more functionality to handle minor changes, reproductions and migrations, I added features as I needed them.  I had spoken about this tool with a few people here and there who I had conversations with when the topic of Zenoss came up and it occurred to me that perhaps, by sharing my tool, I could get some feedback and identify any bugs I overlooked.

So here it is: zenossYAMLTool.py

Zenoss has all the python dependencies that are required to use this tool, except for the python YAML plugin.  So install that and, if you want to make it convenient, place the script into $ZENHOME/bin and run it as the zenoss user.  In order to understand the YAML variables that are used, you should simply use the appropriate export feature on an existing object on your Zenoss instance.  Using my latest addition (-w) as an example, here is a snippet of what a YAML configuration for this tool looks like:

- action: add_window
  windowName: Overnight Maintenance
  windowPath: /Server/Linux/
  duration: 120
  repeat: Daily
  skip: 1
  start: 1299139200.0
  enabled: true

I actually use this tool to generate grouped Multi-Graph Reports from the existing DeviceClasses --- perhaps one day I will revitalize the zenoss-organized-reports into the 3.x release, as I am not so sure that I am 100% satisfied that the current Reporting engine managed to cover all the features I had with my zenoss-organized-graphs back then.