Release Notes 1.0.5
===================

NetSpyGlass v1.0.5


New features
------------

 - Discovery and monitoring of operational state of power supply units and fans has been added for Cisco,
   Arista and Juniper. Since these vendors provide different and incompatible OIDs that expose various metrics
   for power supplies and fans, NetSpyGlass converts values it collects using those to two standardized
   vendor-neutral monitoring variables `psuState` and `fanState` that have value "1" when component is operating
   normally or "0" when it fails. The original variables also appear in the Graphing Workbench and other
   parts of NetSpyGlass UI and can be used for calculations or alerts. For example, one of the variables
   we use to monitor the state of fans on Arista devices actually returns fan speed in rpm. By default NetSpyGlass
   only uses this to check if the fan is spinning, however you could use this variable to set up an alert that
   would activate when the fan is spinning too fast. Original variables provide more fine grained information
   about the component but have incompatible semantics, while unified variables `psuState` and `fanState`
   are more coarse since they reflect only two states, "normal" or "failure", but work across all supported
   vendors.

   * On Cisco we monitor OIDs `CISCO-ENVMON-MIB:ciscoEnvMonSupplyState` or
     `CISCO-ENTITY-FRU-CONTROL-MIB:cefcFRUPowerStatusTable` (whichever is supported by the device) for power supplies
     and `CISCO-ENVMON-MIB:ciscoEnvMonFanState` for fans. Unprocessed variable names are `ciscoEnvMonSupplyState`,
     `cefcFRUPowerStatusTable` and `ciscoEnvMonFanState`; their values are converted to
     `psuState` and `fanState` See functions :func:`psu_cisco()` and :func:`fan_cisco()` in module :mod:`nw2rules`

   * On Arista NetSpyGlass uses OID that measures input PSU current as a proxy for the PSU state. The value is
     collected in the variable `aristaPSUInputCurrentSensor` and is converted to variable `psuState` by function
     :func:`psu_arista` in module :mod:`nw2rules` (operating state is considered "normal" if input current is greater
     than 0). For the fans on Arista, NetSpyGlass monitors fan rpm sensor (variable `aristaFanSensor` ) and converts
     it to `fanState` by also comparing with zero - the fan is considered to be operating normally if the value
     is greater than 0. See function :func:`fan_arista` in module :mod:`nw2rules`.

   * On Juniper NetSpyGlass uses OIDs `JUNIPER-MIB:jnxOperatingState` and tracks state of the power supplies in
     variable `jnxPSUOperatingState` and state of fans in `jnxFanOperatingState`. Their values are converted to
     `psuState` and `fanState`. See functions :func:`psu_juniper` and :func:`fan_juniper` in the same module.

   * you can find Python functions that perform the conversion in the default rules script. The copy of
     the script comes as part of the distribution rpm or deb package in the file
     `/opt/netspyglass/current/python/nw2rules.py`. Search the file for functions :func:`psu_state()`
     and :func:`fan_state()`.

 - Added fields "user" and "reason" to the AlertSilence object. These fields can be set and accessed both via
   JSON API and script `silence.py`

 - added arguments `on_active` and `on_clear` to the function :func:`nw2functions.alert()`. Parameter
   :obj:`on_activate` (if provided and if the value is not `None`) should be a string that consists of
   the full path and optionally command line arguments (separated by spaces) for an external script or
   a program that NetSpyGlass should call when alert goes from state 'cleared' to state 'active'.
   Informtation is passed to this script via environment variables with names composed from `alert_` and
   alert object field name, such as `alert_name`, `alert_deviceName` and so on. The set of fields and
   therefore set of environment variables is the same as the set of variables you can access via macros.
   Parameter :obj:`on_clear` works in a similar way, except the script is called when alert clears (goes
   from the state `active` to state `clear`). These "action" scripts can be used to various kinds of automations
   triggered by alerts.

 - discovered JunOS bug that broke interface CoS queue configurations on some Juniper devices. On devices with
   this bug walking OID JUNIPER-COS-MI::jnxCosQstatTailDropPkts ( .1.3.6.1.4.1.2636.3.15.4.1.11 )
   yields "No Such Instance currently exists at this OID" but walking the parent JUNIPER-COS-MI::jnxCosQstatTable or
   just JUNIPER-COS-MI::jnxCosQstatEntry (.1.3.6.1.4.1.2636.3.15.4.1) returns expected results. I have ran into
   this bug on EX4500 running JunOS 12.3R6.6. This release includes workaround that makes it possible to discover
   interface queue configuration on devices like that

 - Added Python function :func:`nw2functions.skip_nans()` that can be used to filter out monitoring variable
   instances with value NaN before they are fed to :func:`nw2functions.aggregate()`

 - Added ability to discover links between a switche and a server that runs LLDP but does not respond to SNMP
   queries. For this to work and make the server appear in maps it should be added to the configuration.
   Since the server does not respond to SNMP, the community string used in the config can be anything as
   long as it is not empty string.


Bugs fixed in this version
--------------------------

 - NET-1064 : handling of the clock shift because of the leap second