Skip to content

ZenPacks.zenoss.CMDBIntegrationNG

Version

3.6.2

Author

Zenoss Professional Services

About

This ZenPack provides functionality to communicate via JSON interfaces with different CMDB products (e.g., Service Now) or a custom SQL CMDB. If customizations are required for a particular customer site, a new ZenPack that inherits from the ZenPacks.zenoss.CMDBIntegrationNG class will be required.

Features

This ZenPack retrieves devices from an external CMDB system and adds them to Zenoss in the /Discovered device class. It also adds a clickable link for the Configuration Item ID (CI ID) to the device overview page. If a device already exists, the ZenPack leaves it in place and only adds the clickable link for the CI ID. If a device has components in the CMDB, it will add a clickable link for the component's CI ID to the component details tab.

The ZenPack can also optionally retrieve location information for devices, add locations to Zenoss if they don't already exist, and place devices in those locations. The string retrieved from the CMDB for locations will be used to match the name of a location directly under /Locations.

The ZenPack can also optionally retrieve applications from the CMDB that are listed as running on a device. It will create a System organizer for each unique application and place the appropriate devices in those System organizers. This structure can be used to create Impact services.

The following CMDB products are supported:

  • Service Now: the ServiceNow CMDB system
  • SQL: Generic support for an MSSQL or MySQL CMDB
  • Atrium: BMC Atrium CMDB

Prerequisites

Prerequisite Restriction
Product Zenoss 6.4.1 or later
Required ZenPacks ZenPacks.zenoss.ZenSQLTx >= 2.6.3
ZenPacks.zenoss.PS.QFramework >= 1.1.1
ZenPacks.zenoss.PS.Util >= 1.14.5
Other dependencies None

Usage

Common Configuration Fields

The following common configuration fields are available:

Title Default Description
Name None Name for this configuration.
Type None ServiceNow/SQL
Enabled? False Only one configuration can be enabled at a time.

Note: Only one configuration can be enabled at a time.

Title Default Description
Last Successful Run N/A Read-only; date and time that synchronization last ran successfully.
Run Interval 3600 How often the system should poll the CMDB for updates and new items.
Full Run Interval 0 How often the system should check for all items known to the CMDB. This should be left at 0 for any production system. See the note under Polling Interval, below.
Use CMDB IP? True Set the managed IP of the devices created in Zenoss to the IP address from the CMDB. Setting to false forces Zenoss to resolve the device name to determine the IP address.
Use CMDB Location? True Create locations in Zenoss to match the location in the CMDB. Setting to false prevents Zenoss from retrieving any location information from the CMDB. If this is true, the integration will look for a location in Zenoss whose name matches the name from the CMDB. If it finds a match, even if that match is under other location folders, it will use that location. If not, a new location will be created at the root of the location tree.
Use CMDB Application? False Retrieve relationship information from the CMDB about applications that run on the devices synchronized with Zenoss. Create a System organizer for each unique application, and populate with the devices that it depends on.
Zenoss Production States To Lock 300 Don't change Production State of Zenoss devices which are in a state in this list. Namely used to prevent changing Production State of Devices in Maintenance.
Minimum Production State to Create 0 Don't create new Devices whose Production State would be less than this value.
Remove IP Below this Production State 0 Remove the manage IP value when changing Production State to be less than this threshold.
Default Collector for new devices localhost Default collector to assign new devices from the CMDB.
Mapping of production states from CMDB to Zenoss Integration dependent JSON object to map values for Production State from the CMDB to Zenoss.
Mapping of priority from CMDB to Zenoss Integration dependent JSON object to map values for Device Priority from the CMDB to Zenoss.
CMDB Device Field Mappings Integration dependent JSON object to map values for device attributes from the CMDB to Zenoss.
Base organizer for group membership CMDBGroups The default name of a group organizer under which CMDB groups will be created.
List of CMDB group membership mappings N/A JSON-formatted field based on which query CMDB and create corresponding groups in Zenoss. Allowed keys: CMDB_field field of a CI containing group name/names to collect. GroupSeparator character separating group names in case of multiple values in the CMDB_field of the CI. Tag a group organizer to be created under a base CMDB organizer which will contain collected groups from the CMDB_field of a current group membership mapping HierarchySeparator character used to hierarchically separate groups. If used, each group name will be split on this character and subgroups will be created.
Base organizer for system membership CMDBsystems The default name of a system organizer under which CMDB systems will be created.
List of CMDB system membership mappings [] JSON-formatted field based on which query CMDB and create corresponding systems in Zenoss. Allowed keys: CMDB_field field of a CI containing system name/names to collect. systemSeparator character separating system names in case of multiple values in the CMDB_field of the CI. Tag a system organizer to be created under a base CMDB organizer which will contain collected systems from the CMDB_field of a current system membership mapping. HierarchySeparator - character used to hierarchically separate systems. If used, each system name will be split on this character and subsystems will be created.
CMDB Top Level Service Organizer CMDBApplications The top-level Impact service organizer in which to create Application services.
Device ProductionState filter for discovering impact services -1 Devices with a production state below this value will not have their relationships checked for Impact services.
CMDB Default Service Organizer CMDBServices The default Impact service organizer in which to create Application services.
Zenoss To CMDB Field Mapping None A list of mappings from Zenoss fields to CMDB fields. The Zenoss field can be a TALES expression instead of a field name. Note that support for this is integration-dependent.
Components to Push to CMDB None Defines the set of component types to push to the CMDB. Support for this is integration-dependent. Support for this is integration-dependent. Common features are that each component type is defined by a Zenoss meta type, and you can provide a set of regex filters to match against fields on the components. There will also be a target CMDB class defined. The integration will define how field mapping is handled, since different CMDBs will have different ways of representing the relationships.
Create devices from discovered configuration items? True If false, devices will not be created in Zenoss, though existing devices will be linked to CMDB CIs.
Send Event when Zenoss device created? False Send an informational event when a device is created, tied to that device.
  • Toggling the Enabled flag off will remove the existing CI IDs from all devices in the Zenoss system. Toggling it back on will not restore those IDs; the system will need to poll for all of the devices and re-associate the CI IDs to the Zenoss devices.
  • The option to migrate performance data has been removed throughout the product.

Device Field Mapping

In general, the Zenoss field in the mapping should fall into one of a couple of patterns.

  • The simplest are simply attributes of the device, like manageIp.
  • The second are attributes of either the HW or OS object. These should be specified as, for example, os.version or hw.tag.
  • The third are special fields that are not directly accessible as attributes. This includes productionState, name, performanceMonitor, and devicePath.

The performance Monitor field allows you to set the collector for a device. Use the name of the collector, as you would see in the UI.

There MUST be a mapping for the productionState field because every Zenoss device MUST have a valid production state. The value in whatever field is mapped to productionState is first translated using the mapping in the configuration item labeled "Mapping of production states from CMDB to Zenoss".

The name field is used for the Zenoss device ID. Every device in Zenoss MUST have an ID, so you SHOULD make sure to map a value to name. However, the system does have some logic it uses to try to identify a value for name if one is not provided.

  1. The system will use the value mapped to name if it exists and is a non-empty string.
  2. If not, it checks if a value has been mapped to title, and if so, and it is a non-empty string, it will use that.
  3. If that also fails, it checks if a value has been provided for managelp. If so, and it's a valid IP address, it will use that value for the name.
  4. If all of these fail, the system will log an error, create an event, and not try to create the device.

The devicePath field allows you to put devices into a device class other than /Discovered. The value mapped to this field MUST be a valid device class path, beginning with the / character. An example is /Server/SSH/Linux. Any values that are not valid device class paths will be ignored and a log message will be generated. The devicePath field is only used on device creation; devices will not be moved from one device class to another.

Group/System Membership Mapping

These fields allow you to map fields in the CMDB to either group or system membership for the devices being pulled from the CMDB. The CMDB field can contain multiple group names and those names can have multiple hierarchical levels.

These fields need to contain valid JSON with the following fields:

  • Tag (optional)
  • CMDB_field (required)
  • GroupSeparator (optional)
  • HierarchySeparator (optional)

The Tag defines a level in the group (or system) hierarchy between the base organizer and the organizer created from the value in the CMDB field. The GroupSeparator should be a single character and allows the CMDB field to contain multiple groups (or systems) separated by that character. The HierarchySeparator allows the field to contain multiple levels of group (or system) membership.

Here's an example: Assuming the following fields have the content shown:

  • Base organizer for group membership: CMDBGroups
  • Base organizer for system membership: CMDBSystems
  • List of CMDB group membership mappings: 
    [{
  "Tag": "Customers",
  "CMDB_field": "dv_team_group",
  "GroupSeparator": ";",
  "HierarchySeparator": "/"
}, {
"Tag": "Public DMZ",
"CMDB_field": "dv_public_dmz"
}]

And the CMDB fields have the following content:

  • Contents of dv_team_group: CriticalCustomers/CustomerA; EMEA/CustomerA

  • Contents of dv_public_dmz: DMZ1

    Then the resulting group membership for the device will be:

[
  "/CMDBGroups/Customers/CriticalCustomers/CustomerA",
  "/CMDBGroups/Customers/EMEA/CustomerA",
  "/CMDBGroups/Public DMZ/DMZ1"
]

Remove IP Below this Production State

When the CMDB integration changes a device's production state to a value below this threshold, it will remove the managelp value. With the default threshold, this will only affect devices being decommissioned, as the value for that production state is -1. The IP address is completely removed and will not reappear if the production state is reset unless the CMDB integration is getting that IP from the CMDB.

To disable this functionality, set the threshold to a value lower than any defined production state, such as -1 or lower for the default production states. This functionality prevents collisions with decommissioned devices when IP addresses are re-used by new devices coming from the CMDB. You can keep the decommissioned device in Zenoss for historical data viewing while allowing the integration to create a new device with the same IP address.

Polling Interval

The Polling Interval, or cycletime, determines how often the database is polled and checked for updates in seconds. This is configurable in the zencmdbpoll.conf service configuration file. In Zenoss v5, this is accessible by opening the zencmdbpoll Service in Control Center, editing the Configuration file, and restarting the Service.

Starting with version 2.0.0, the cycletime for zencmdbpoll is not used to control the polling interval. Instead, set the full and incremental polling intervals in the CMDB configuration screen. A full run queries everything from the CMDB that matches the filter, while an incremental run only queries objects that have changed since the last run, which is much faster. Objects in the CMDB that were not associated with a device or component in Zenoss and have not changed will not be queried in an incremental run. If components have been added to a device in the CMDB but the CMDB does not register that as a change to the device, those components would not be linked in Zenoss.

Note: Changing the CMDB configuration in Zenoss will trigger the next run to be a full, rather than incremental, run, regardless of the poll cycle settings. The full polling interval in a production system should generally be set to 0, which disables it. In a test system, setting this to a non-zero value is acceptable for easier and faster testing.

Test Access to CMDB

The Test Access button can be used to check the connection to the CMDB system. You need to select a Configuration Item and click the button. The result will be displayed in a pop-up dialog box.

Services

This ZenPack installs three services into the system:

  • ZenCmdbPoll: Responsible for querying the CMDB and adding/updating devices in Zenoss.
  • ZenCmdbPush and ZenCmdbPushWorker: Responsible for listening for changes to the model in Zenoss, checking if any fields configured to be sent to the CMDB are different from whats currently in the CMDB, compiling lists of components to send, prepping updates, and sending them to the CMDB.

Not all implementations support the push functionality, but the services will be present regardless. If you are not configuring the system to send any information to the CMDB, these services can be safely disabled.

Installing

Install the ZenPack via the command line and restart Zenoss:

zenpack --install ZenPacks.zenoss.CMDBIntegrationNG-<version>-py2.7.egg zenoss restart

Removing

To remove the ZenPack, use the following command:

zenpack --erase ks.zenoss.CMDBIntegrationNG zenoss restart

Troubleshooting

The Zenoss support team will need the following output:

  1. Set the zencmdbpoll daemon to DEBUG level logging by typing zencmdbpoll debug from the command line. This ensures all activities are visible in the zencmdbpoll.log file.

Logging

Log files are kept in the following locations under the $ZENHOME/log/ directory:

Source Log Location
CMDB synchronization zencmdbpoll.log

ServiceNow

This integration queries ServiceNow for devices to monitor. It can also query for components of those devices to link to components discovered by modeling. The integration can push configured component types to ServiceNow as updates to devices, as well as pushing the value of certain device fields. It can also query relationships in ServiceNow to create Zenoss Service Impact services that include devices and components in Zenoss.

The integration supports pagination in ServiceNow's API responses, so it will retrieve all information regardless of the default limit set in ServiceNow for API returns.

Dependencies

While not required, it's recommended to install the Zenoss CMDB Integration ServiceNow app from the ServiceNow App Store. This app creates a read-only role that gives access to all necessary CMDB tables for the integration. The listing in the app store documents the installation of the app, and the role that is created.

The user ID for this integration also needs the itil role if you intend to push information back to the CMDB, as the app's role is strictly read-only.

Create a ServiceNow CMDB Configuration

The following ServiceNow-specific configuration fields are available:

Title Description
URL URL for your ServiceNow instance.
Username Username for your ServiceNow instance. User needs read-only access to all CMDB tables (cmdb_ci*).
Password Password for your ServiceNow instance.
CMDB Device Tables Comma or carriage-return separated list of tables to query for device data. ServiceNow tables implement inheritance, so using a general table, such as cmdb_ci_computer, will also get records from more specific tables, such as cmdb_ci_linux_server.
CMDB Filter Expression ServiceNow query to limit results to devices that should be in Zenoss. This query should be constructed by a ServiceNow administrator (ServiceNow has tools for creating queries).
Mapping of production states from CMDB to Zenoss JSON-formatted field to allow customization of mappings from ServiceNow operational status to Zenoss Production State. Should only be modified with assistance from Zenoss Professional Services.
CMDB Tables for Component Information JSON-formatted field to allow customization of tables to query for component information. Should only be modified with assistance from Zenoss Professional Services.
CMDB Device Field Mappings JSON-formatted field to allow customization of mappings from ServiceNow device fields to Zenoss. Should only be modified with assistance from Zenoss Professional Services.
CMDB Application relationships JSON-formatted field to allow customization of tables to query for device/application relationships. Should only be modified with assistance from Zenoss Professional Services.
Maximum Request Length for URL The maximum length of the URL to allow when generating queries for device information. Can be reduced from the default 7000 for systems that may have a smaller limit.
Components to Push to CMDB A JSON object defining the set of component types to push to the CMDB. The structure is described in more detail below.

Components to Push to CMDB

This feature creates component CIs in the CMDB corresponding to components of devices in Zenoss. It only creates components for devices that already have a CI ID (i.e., the device is already in the CMDB). It also creates the relationship from the device to the component.

This is done using ServiceNow's Identification & Reconciliation API, their preferred method for third-party tools to push information into the CMDB. Because it uses this API, the ServiceNow administrator has complete control over whether components are added to the CMDB, how they are named, and whether they overwrite existing information.

Configuring those reconciliation rules is not necessary, though, and is outside the scope of this document. See ServiceNow’s documentation for more information.

Here is a sample configuration to push interface components from Zenoss into the CMDB:

{
  "IpInterface": {
    "filters": [],
    "cmdbClass": "cmdb_ci_network_adapter",
    "fieldMapping": {
      "interfaceName": "name",
      "${comp/getIpAddress}": "ip_address",
      "macaddress": "mac_address",
      "description": "short_description",
      "${device/configurationItemId}": "cmdb_ci"
    },
    "relationship": {
      "type": "Owns:: Owned by",
      "parent_entity": "device"
    }
  }
}

The Zenoss meta type this will look for is IpInterface. With no filters defined, it will push all found interfaces. This is equivalent to the following filter:

{
  "regexField": "name",
  "regex": ".*"
}

The CMDB class is cmdb_ci_network_adapter, so components will be created in that table. The field mapping uses the interfaceName attribute to populate the name field in ServiceNow. It uses a TALES expression to get the IP address from the interface to set the ip_address field. It also uses the macaddress and description attributes to populate the mac_address and short_description fields, respectively. A TALES expression is used to retrieve the CI ID for the device and set the cmdb_ci field in ServiceNow to that value. This links the device and component in the ServiceNow UI.

A relationship object is also specified to explicitly tell ServiceNow how the device and component are related. The example uses the "Owns::Owned by" relationship, where the device is the parent and the component is the child.

CMDB Filter Expression

The best way to create ServiceNow filter expressions is to use the graphical filter builder in ServiceNow, which is available when browsing any CMDB table (e.g., cmdb_ci_computer). Click the funnel icon to begin configuring that filter.

The filter builder allows you to choose the field from a drop down list (e.g., ’Class’), the operator from a drop down list, which will change depending on the field type (e.g., ’is’), and the comparison value, which will also change depending on the field type (e.g. ’Linux Server’).

You can build complex queries by selecting AND or OR operators and adding additional criteria. Once you have built your filter, click ’Run’, and check that the results are the list of devices that you expect. After verifying the results, right-click on the rightmost portion of the filter expression shown and choose Copy Query to paste it directly into the CMDB Filter Expression field in the CMDB configuration in Zenoss.

About API Support

This integration depends on the ServiceNow REST API, which should be present and enabled in all recent releases of ServiceNow.

Tips

  • In ServiceNow, right-click on an item to find its underlying field name at the bottom of the menu.
  • A magnifying glass next to a field indicates it refers to something else; you will need to find which field is used as the base for this field.
  • On many screens, the hamburger menu has a "Show XML" option to view the actual field names and values for a record.

CMDB SQL

This ZenPack implements a generic SQL interface to custom SQL-backed CMDBs. It builds SQL queries for device population based on a mapping of table fields to Zenoss properties. Application support is also included for building System organizers to populate with devices. (Note: Since the queries can be customized, these organizers are not limited to only Application data, but could be used for displaying any hierarchy, e.g., Datacenters or device hardware models.)

Unlike other integrations, clickable links are not generated in the UI because they are meaningless for a pure SQL-based solution.

Dependencies

This SQL integration requires an additional dependency: ZenPacks.zenoss.ZenSQLTx >= 2.6.3. Without this installed, you will not be able to configure an SQL implementation.

Configuration

The following configuration fields are available:

Database

Title Description
Database Type Choose the Database Engine (MS SQL, MySQL)
Database Host Hostname or IP address of the Database Server
Database Port Port number to use for connections - set 0 to use default (MSSQL: 1433 MySQL: 3306)
Database Name / User / Password Database connection information (user can and should have read-only access)

Queries and Mapping Device Tables Mapping

This is the main configuration for the CMDB, a JSON dictionary whose keys are table names and values describe the mapping of columns to Zenoss fields. The ci_id_field is required and will return a consistent, unique ID for the device, typically the primary key for the table.

Common zenoss_field_name possibilities are described below in Common Zenoss Fields:

{
  '<tablename>': {
    "ci_id_field": "<sql_column_name>",
    "filter": "<optional WHERE clause filter>",
    "customFieldDefs": {
      "<sql_column_name>": "<custom SQL definition>"
    },
    "fieldMapping": {
      "<sql_column_name>": "<zenoss_field_name>"
    }
  }
}
  • ci_id_field: Specifies the SQL field name to use when generating the CI ID.
  • filter (Optional): Applies a filter to the generated query when retrieving a list of IDs from the database.
  • customFieldDefs (Optional): Applies custom SQL field definitions to fields defined in fieldMapping.
  • fieldMapping: Maps SQL fields to Zenoss CMDB Fields.

This builds simple, single-table SQL queries, such as:

  • Id List: SELECT <ci_id_field> FROM <tablename> [WHERE <filter>]

  • Details: SELECT <ci_id_field> [, <sql_column_name>] [, <custom SQL definition> AS '<sql_column_name>'] FROM <tablename> [WHERE <ci_id_field> IN (<id_list>)]

Note: This integration does not currently support retrieving device details spanning multiple tables or views. A single view would be needed to retrieve all details for a device.

Default Device Class

  • Default: /Discovered
  • The default device class where new devices are added.

Device Class Mapping

  • Default: {}
  • This is an optional configuration to map new devices to a specific DeviceClass. It uses the deviceClassName field specified in the Table Mapping to look up the value for DeviceClasses.
{
 "<deviceClassName>": "<DeviceClass>",
 }

Example:

{
  "Windows": "/Server/Microsoft/Windows",
  "Linux": "/Server/SSH/Linux"
}

SQL Queries for Applications

  • Default: {}
  • This builds Organizers under /Systems in Resource Manager and populates them with Devices. The setting is a JSON dictionary of table names containing a list of SQL queries to run to generate the Applications organizers.

Organizers are created relative to the CMDB Top Level System Organizer.

The first field returned by the query MUST be the ci_id of the device as returned by the Device Tables Mapping for the tableName. Subsequent fields are built into the organizer path, with each field comprising one level of the hierarchy.

{
 }
 "<tableName>": [
 "any number of queries for",
 "this table"
 ],

Example:

{
  "server_roles": {
    "servers": [
      "SELECT server_id, 'SERVER_ROLES', role_name FROM device_applications;"
    ]
  }
}

This would generate Organizers such as /Systems/CMDBApplications/SERVER_ROLES/db, where:

  • CMDBApplications/ is defined by the CMDB Top Level System Organizer.
  • SERVER_ROLES/ is a constant returned in the SQL.
  • db/ is generated from the returned role_name.

CMDB Top Level System Organizer

  • Default: CMDBApplications
  • The top-level System Organizer where Application Organizers are created. This may be blank to create them directly under /Systems.

Mapping of production states from CMDB to Zenoss

This is a dictionary that maps CMDB Device Status (see cmdbStatus field below) to Zenoss Device Production States. If cmdbStatus is not set in the Device Tables Mapping, the device defaults to a cmdbStatus of empty string "", so at minumum this value should be provided in the map.

Example: { "": "1000" }

You can see the full list of configured Production Statesd in the Resource Manager Advanced Settings Page. (https://docs.zenoss.com/rm/appendix/advanced-settings.html)

Default Production States and their values are: | Production State | Value | | :--- | :--- | | Production | 1000 | | Pre-Production | 500 | | Test | 400 | | Maintenance | 300 | | Decommissioned | -1 |

Delete Devices not found in CMDB

This option enables deleting devices from Zenoss that are no longer in the CMDB. When running zencmdbpoll, any device whose ci_id is not in the list returned from the query will be removed. This feature should be used cautiously and is intended only for cases where devices are completely removed from the CMDB rather than being placed into a decommissioned state.

Common Zenoss Fields

These are some of the common Zenoss fields available in the Table Mapping:

Title Description
managelp Sets the managelp for the device, which Zenoss will use for monitoring.
title Sets the Title for the Device.
name Defaults to title or managelp, in that order.
cmdbStatus This value, queried from the CMDB, is mapped to a Zenoss Device Production State by the Mapping of production states from CMDB to Zenoss table above. If not provided by the CMDB query, this value will default to "".
devicePath DeviceClass in which to create the new Device (Default/Discovered).
deviceClassName Typically set via the Device Class Mapping table above. Lookups for DeviceClass (see Device Class Mapping).

Changelog

3.6.2

  • Fixes
    • SVC-4028 This fix ensures that the password fields are fully hidden in the UI

3.6.1

  • Fixes
    • SVC-4026 Catch and retry Unable To AcquireCommit Lock errors

3.6.0

  • Fixes
    • SVC-3658 Fix formatting for Prerequisite ZenPacks table in docs
    • SVC-3863 Fix retry after conflict errors
  • Features
    • SVC-3818 Support pagination in the ServiceNow API; limit initial query for sys ids to 5000 per page
    • SVC-3559 Provide an example for Group/System membership mappings
    • SVC-3520 Add filter to prevent processing invalidations when CMDB configuration is changed
    • SVC-2756 Move device to new device class based on CMDB
  • Fixes
    • SVC-3988 Function _removeMissing Devices needs inline callbacks decorator because it tries to yield a deferred
    • SVC-3987 getSetting needs to use integration type rather than name to get adapter

3.5.2

  • Fixes
    • SVC-3824 Fix table formatting in docs

3.5.1

  • Fixes
    • SVC-3791 Workaround for ZSD regression on model change events
    • SVC-3792 Fix bug where getCmdbMultiple DeviceDetails would get called with wrong data type when checking if it needs to push updates to the CMDB

3.5.0

  • Features
    • SVC-3759 Add router and facade method to set CI ID on devices via API
    • SVC-3772 Add jobs support for Garfield release of CZ
  • Fixes
    • SVC-3696 Ensure we fire indexing event after updating devices
    • SVC-3762 Add zencmdbpush and zencmdbpushworker services on upgrade if they are not there
    • SVC-3542 Ensure CI ID is not lost when renaming device
    • SVC-3786 Update last RunFinished and last RunSuccessFinished on full runs so we don't keep trying to do a full run after first full run for new config

3.4.1

  • Fixes
    • SVC-3655 Don't disable active configuration when editing inactive configurations
    • SVC-3656 Don't change type of migratePerfData param when saving
    • SVC-3657 Change default for migratePerfData
    • SVC-3660 Protect enable radio button on CMDB configs, since clicking doesn't change status of config

### 3.4.0

  • Features
    • SVC-2936 Make CI details queries more efficient for ServiceNow
    • SVC-3216 Catch and retry database conflict errors
    • SVC-3400 Add fields for Last successful full run, last full run started, last full run finished, and last successful full run finished
  • Fixes
    • SVC-3294 Remove unused setChangeControl method from facade
    • SVC-3561 Ensure devices can get picked up by DiscoveryMapping when created
    • SVC-3610 Fix issue where moving device fails with "BadRequest: Id cmdbClass is invalid or duplicate"
    • SVC-3617 Fix AttributeError when updating non-string cProps and zProps
    • SVC-3619 CMDB ZP incorrectly sees all non-string property values as different from CMDB
    • SVC-3624 Fix CI ID being lost when moving devices between device classes with same python class
    • SVC-3637 Fix order of logging when associating a CI ID to a device

3.3.2

  • Fixes
    • SVC-3547 Fix bug preventing zencmdbpoll from picking up a newly enabled config without a restart

3.3.1

  • Fixes
    • SVC-3535 Fix IP address query for Atrium

3.3.0

  • Features
    • SVC-3258 Add dry run option to CMDB Config dialog
    • SVC-3307 Validate that CMDB Application Relationships has all required fields
    • SVC-3353 Allow zencmdbpoll to create Systems as well as Groups
    • SVC-3389 Look for locations before creating or updating devices to support hierarchical locations
  • Fixes
    • SVC-3008 Remove Migrate Performance Data When Automatically Re-Identifying Devices from CMDB
    • SVC-3311 Ensure dry run button does not save config
    • SVC-3316 CMDB ciid lost when moving device between deviceclasses with different python types
    • SVC-3343 CMDB zenpack documentation needs to state that it requires ps.util
    • SVC-3377 Streamline logic around when to run (and do full runs) in zencmdbpoll
    • SVC-3388 Zencmdbpoll still missing heartbeats

3.2.0

  • Features
    • SVC-2720 Add events for duplicated IP address and device id
    • SVC-2985 Added audit statements for device creation and renaming, production state changes, device priority change, location change, component updates
    • SVC-3105 Allow user to remove CI ID from a device in the UI
    • SVC-3158 Iterate through component CI IDs also to look for services in the CMDB
    • SVC-3217 Update ServiceNow information in docs
  • Fixes
    • SVC-2397 Ensure failure of cmdb poll does not cause process to fail, and that we reset next run or next full run so we don't wait a full interval to try again
    • SVC-3027 Ensure Test Access button gives correct results for all CMDB types
    • SVC-3171 Convert set of components to list to allow chunker to chunk the list to send to the CMDB
    • SVC-3173 Ensure we pass a list to the chunker function
    • SVC-3175 Fix traceback when querying CMDB for Impact information
    • SVC-3260 Exclude notification windows when caching maintenance windows

3.1.2

  • Fixes
    • SVC-3169 Update change management calls in facade to end maintenance windows before deleting group, so devices aren't left in maintenance when window is cancelled during the window

3.1.1

  • Fixes
    • SVC-3159 Don't automatically do a full sync when daemon restarts

3.1.0

  • Features
    • SVC-2928 Moving Atrium to use newer PS.Util http client, and using plugin for auth
    • SVC-3046 Detect when credentials have changed and restart JsonApi object to pick up
    • SVC-3050 Update logging to ensure all configuration settings are logged in debug

3.0.0

  • Features
    • SVC-2186: Implement a getSettings method for the CMDB config
    • SVC-2261: Update documentation to fully describe effect of the Enable button
    • SVC-2527: Heartbeat messags are not sent while poll is running
    • SVC-2620: Use standard chunking function from PS.Util
    • SVC-2627: Update to use PS.Util http_client
    • SVC-2621: Make zencmdbpoll work better with twisted
    • SVC-2808: Explicitly set last change on device after adding
    • SVC-2962: Avoid unneccesary json encoding and decoding of body data for requests
    • SVC-2847: Preserve CI ID when moving a device between classes
    • SVC-2537: Add zing-connector healthcheck to zencmdbpoll
    • SVC-2927: Remove IP address object if appropriate when decommissioning device
    • SVC-2984: Prevent user from setting full run interval shorter than run interval
    • SVC-2954: Add support for OAuth for ServiceNow to CMDB ZP

2.2.4

  • Fixes
    • SVC-2916: Gracefully handle no group mappings.

2.2.3

  • Fixes
    • SVC-2872: Prevent traceback error in transaction commit when no CMDB config is enabled

2.2.2

  • Fixes
    • SVC-2857: Prevent tracebacks when no fields are going to be sent to CMDB to prevent stuck messages in queue

2.2.1

  • Features
    • SVC-2810: Remove managelp when decommissioning a device
    • SVC-2814: adapt zenjobs propertypatcher hook to work with either pre/post zenjobs rewrite
  • Fixes

2.2.0

  • Features
    • SVC-1961: Add the ability to map a CMDB field to Zenoss collector, and change collector if that changes
    • SVC-2755: Add the ability to map a CMDB field to Zenoss device class to set device class on device creation
  • Fixes
    • SVC-2518: Ensure all error and warning log messages also create events in the event console
    • SVC-2230: Ensure errors updating CMDB fields are counted as errors for zencmdbpoll
    • SVC-2628: Fix prodstate changes during maintenance windows
    • SVC-2631: Fix cmdbClass not being reset by zencmdbpoll
    • SVC-2771: Fix bad collector name causes _checkDeviceExists to fail
    • SVC-2780: Fix in zencmdbpoll, compare is broken for fields to send to CMDB
    • SVC-2757: Clean up documentation

2.1.4

  • Fixes
    • SVC-2762: fix issue where transaction post commit hook can fail under certain circumstances

2.1.3

  • Fixes
    • Fix CMDB config disappearing from Advanced Menu

2.1.2

  • Fixes
    • Fix zencmdbpushworker failures when a Device added/updated

2.1.1

  • Fixes
    • Fix 'qualification' filter in Atrium

2.1.0

  • Fixes
    • SVC-2486: fix CMDB config disappearing from Advanced Menu
    • SVC-2185: add raw data to logging in case of error in nameFallThrough
    • SVC-2572/SVC-2576: fix traceback on device/components removal
    • SVC-2577: fix zenjobs hanging when CMDB installed

2.0.4

  • Fixes
    • SVC-2560: fix to allow field updates to be pushed to CMDB when no components are being pushed

2.0.3

  • Fixes

    • SVC-2547: Atrium: Update URL to use instances instead of instance
    • SVC-2558: Atrium: Chunk IP addresses before query to avoid URI too long error messages
    • SVC-2559: fix model event message monkeypatching so it only happens when it needs to

2.0.2

  • Fixes
    • SVC-2535: update ciid index on guid change and add fallback for dmd value in case object is not yet persisted
    • SVC-2513: check if component ciID exists
    • SVC-2529: removed redundant compsToPushToCMDB definitions
    • SVC-2534: Explicitly fire event so that property patching happens in the zencmdbpushworker process

2.0.1

  • Fixes
    • SVC-2528: fix property patcher to avoid stale dmd reference

2.0.0

  • Features
    • SVC-2182: Push limited component changes to CMDB
    • SVC-2182/SVC-2425: Added metric instrumentation of cmdb daemons
    • SVC-2182/SVC-2325: Improved logging and events
    • SVC-2398: Added full and incremental poll cycle configuration
    • SVC-2398/SVC-2221: Added force run button to config UI
  • Fixes
    • SVC-2421: batch servicenow cmdb updates to avoid errors
    • SVC-2417/SVC-2231: fixed inconsistent CIID index issues
    • SVC-2417: improved duplicate CIID detection
    • SVC-2417/SVC-2439: ensured poll does not stop on common errors
    • SVC-2417: fixed 'Production States to Keep' functionality
    • SVC-2417: fixed 'use CMDB Ip Address' functionality
    • SVC-2425/SVC-2230: count cmdb update errors as errors

1.12.3

  • Fixes
    • SVC-2402 SVC-2403 SVC-2404: fixes for discovered bugs/regressions
    • SVC-2400: reinstate createDevices control setting while ensuring lack of creation does not inhibit association or update of existing devices

1.12.2

  • Fixes
    • hotfix 1.12.2: fix cmdbStatus migration so it commits

1.12.1

  • Fixes
    • SVC-2375: fix productionState mapping
    • SVC-2381: fix default value for cmdbKeepProdStates and migrate existing configs
    • SVC-2367: add agent field to zencmdbpoll events
    • SVC-2368: log actual device id when changing device ids
    • SVC-2372: SNOW: allow both the raw field and dv_field values to be mapped

1.12.0

  • Features
    • SVC-130: Add 'Test Access' button into UI
    • SVC-2269: Add feature to map devices to Device Groups based on CMDB field contents
  • Fixes
    • SVC-2252: fix improper and inefficient behaviour in change window setting
    • SVC-2256: Patch properties onto device classes when zenjobs starts up
    • SVC-2363: linking ci id to existing device if its ci id is not set
    • SVC-2363: raising event for duplicate CI IDs

1.11.0

  • Features
    • SVC-2033 Add backend procesor to handle communications with RM
    • SVC-2073 Implemented tests for associating ci's to devices and components, disassociating CIs from devices and components, decommissioning and deleting devices
    • SVC-2084 Refactor zencmdbpoll to use new backend processor
    • SVC-2184 Remove Additional Field Mappings, migrate any existing settings to the standard device field mappings
    • SVC-2187 Fix undefined name errors caused by not importing all necessary modules
    • SVC-2223 Ensure properties we are setting actually exist so we don't create unwanted attributes
    • SVC-2224 Remove code that was made obsolete or redundant by the new backend processor

1.10.1

  • Features
    • Add zing-connector endpoint for Zenoss Cloud compatibility.

1.10.0

  • Features
    • ServiceNow add maxRequestLen to config to override default
  • Fixes
    • Properly map SN 'dv' fields.

1.9.1

  • Fixes
    • Fix check for location in returned data

1.9.0

  • Features
    • added event generation for CMDB run
  • Fixes
    • fixed setChangeControl to work correctly
    • typo fixes

Attachments