Two new vendor-modules were added. Support for Gigamon GigaVUE and Meinberg LTOS was added bringing the total of supported Vendor device families up to 33.

Currently our conditions support a couple of options which only work when the Rule Start and/or Rule End are used. Therefore will now hide those options when one of those fields are blank.

We have hidden the must contain lines and order options from compliance conditions that deal with the full config. We have also hidden the comments for ConfigText conditions

Intermittently a call to the XchRest API failed with an 'internal server error' (code 500).

The problem was caused by an invalid call to cleanup function that removes expired OAuth tokens. This function is invoked every tenth request. The issue is resolved.

When changing the Domain value of a node, this change did not result in a re-scheduling of a compliance check. For most compliance policies the actual Domain assigned to a node is not relevant as the Domain is primarily used to retrieve the credentials needed to the configuration retrieval. But when policies use conditions where the configuration is tested against actual values associated with the Domain, a Domain change becomes very relevant for the compliance results.

Conditions in policies can access NetYCE variables using the <variable> syntax causing the condition to test against associated data. As the Domain is often used as such a source, compliance re-scheduling for the affected node is worthwhile. Therefore, the NCCM refresh flag now gets set when re-assigning a Domain of a node.

Of course, many other NetYCE objects other than Domain can be used in the conditions, and these will not trigger this compliance re-scheduling. For those cases the intended setup involves scheduled compliance policies that will be executed at fixed intervals regardless of changed variables or assigned objects.

Configuration backups (Nccm) are normally retrieved from the network devices. For migration or integration purposes these configurations can also be submitted using the Xch api. However, when doing so for a new device, the new device and its config would not be displayed in the Backups form. Only after a different trigger to renew the polling selection (like adding a cmdb node manually) would the node show up in the grid.

Additionally, the Xch nccm submit call was extended to include a new optional attribute, nccm_polltime, to override the polling timestamp of the submitted configuration. However, as with GIT and other 'diff' based storage engines, the NCCM cannot process submitted configurations out-of-order. The provided polling timestamps are mostly administrative and the submitted configuration is still considered the 'latest' superseding the previous. The option is useful mostly to submit a series of configurations taken at different historical moments.

The 'node' endpoint of the XchRest suffered from several shortcomings on its initial inclusion. This endpoint is intended to allow full create, read, update and delete (CRUD) functionality of the CMDB nodes, but will now support the read (list) function only. The filter, start and length attributes are included and the returned node records will no longer show error messages.

The Wiki article describing the XchRest API outlines the setup of a 'Postman' configuration to get familiar to with the use of this new API. It also refers to the on-line schema documentation but failed to point out that this documentation could not be used for actual transactions as the 'authorize' and 'Try it out' buttons advertize.

As it turns out, this on-line schema could be modified to support the required OAuth authorization and use the proper url's to get the 'try it out' functional. Using this interface to give the API a first look will be a helpful first step before experimenting with a Postman or Python approach.

On the subject of Python, a XchRest sample client will become available shortly thanks to the helpful submission by one of our customers.