Page tree
Skip to end of metadata
Go to start of metadata

This page provides a brief overview of the major changes between opHA3 releases.

Introduction

opHA introduces the concept of a Primary & pollers servers:

  • The Primary is the node that have the information of all the pollers and it is where we can read all the information from.
  • The pollers, collect their own data, and send that information to the Primary when it is requested. 

The process of synchronising the information of the nodes is made by the Primary. The Primary requests the information for each poller with pull requests. 

The first time the script runs, it is going to request all the data for each configured poller. Next time, it is going to request only the modified data since the last synchronisation. 

3.3.2

RELEASED 19 Oct 2021

This release includes:

  • Redundancy in primary servers
  • Authorisation for users in the GUI functions. The administrator can do all read and write operations, other users can just read. 
  • System menu updated.
  • Use a password field in Discoveries from the GUI. 
  • Updated expire_at fields from inventory, a wrong format was being saved.

3.3.1

RELEASED 24 Aug 2021 

This release includes:

  • Bug fix that was not synchronising the correct nodes in specific cluster configurations with a mirror. 
  • Bug fix to View effective configuration Files from the pollers (When the poller has configuration files overriding the configuration). 
  • Updated help links.
  • Added a clean_data cli tool action to clean up the data for one peer.

3.3.0

RELEASED 10 Jun 2021 

This release includes two new features:

Another small improvements has been made in the GUI. 

3.2.1

RELEASED Released March 10, 2021.

Upgrade Notes

This release resolves issues with MongoDB connection leaks through our applications.

3.2.0

RELEASED Released Sept 30, 2020.

Upgrade Notes

The new upcoming release of opHA 3 will work on Opmantek's latest and fastest platform, however, the currently installed products are incompatible with this upgrade. 
To find out more about this upgrade please read: Upgrading Opmantek Applications

3.1.2

RELEASED Released Jul 03, 2020

  • Fix for configuration files that were not be read in conf.d directory (opCommon and Config). 
  • Removed error from logs that was not able to read conf.d. 
  • Now is not possible to discover a peer with same cluster_id than other poller or the Primary.
  • Updated cli tool get_own_config. 
  • Internal minor fixes in the installer:
    • support tool is updated now. 
    • updated function for convert json files in common-cli. 

3.1.1

RELEASED Released Jun 30, 2020

  • Fix for configuration files with duplicate extension. Now the GUI uses the extension as there are 2 format files: NMIS and JSON. 
  • Internal minor fixes in the installer.

3.1.0 

RELEASED Released Jun 24, 2020

  • JSON Configuration files: The .nmis configuration files will be replaced by .json files
  • New License 2.0 structure used. 
  • ! Important note: Due to the JSON configuration files upgrade, when updating to this version, upgrade all OMK Products installed will be required (Not NMIS) to at least X.1. version. It also requires a License update due to the new license structure. 

3.0.8 BETA

Released Jun 2, 2020

  • Bugfix: Discover peer window was closing when required fields missing. 
  • Bugfix: Update the last_update field to the synchronisation. This was causing some data not being updated in the Primary and expire_at field for events not being updated in all the documents. 
  • New cli cleanup functions to clean data from the cli tool.
  • Added new cli function get_status to get the status for each poller in json format. 
  • Some minor bug fixes and internal improvements. 

3.0.7 BETA

Released December 26, 2019
opHA 3.0.7 requires NMIS 9.0.6

3.0.5 BETA

Released August 22, 2019
opHA 3.0.5 requires NMIS 9.0.6

3.0.4 BETA

3.0.3 BETA

  • Support for node deletion on the pollers. When a node was deleted on the poller, all this data wasn’t remove on the Primary. Now the pull process is going to remove nodes and associated data that was removed on the poller.
  • Retry policy on pull failures: If there was a failure during the poller update, the pull finished. Now it is possible to specify a retry policy:
    • retry number: How many times retry a request before finish the process unsuccessfully. 3 is the default value.
    • delay: How many seconds is going to wait between retries (5 seconds by default).
  • It is possible to modify this params in opCommon.nmis:


'opha_transfer_chunks' => { 
      'inventory' => 500, 
      'nodes' => 500, 
      'events' => 500, 
      'status' => 500, 
      'latest_data' => 500,
      'retry_number' => 3,
      'delay' => 5
    },


Note that if no option is specified, there is not going to do any retry. 

Also, note that if a poller is down, the process is going to take retry_number * delay seconds to finish. 

  • Show the registry synchronised data on the GUI. 
  • Small improvements on the GUI. 

3.0.2-1 BETA

Hot fix to solve the problem of visualise the nodes graphics of the poller from the Primary. 

3.0.2 BETA

On this version, the Primary is going to request the information by chunks. The number of calls is based on the chunk size and the number of results. The chunk size can be modified on conf/opCommon.nmis on the poller, with the next parameter (Note that a service restart is needed to use the new parameters):

 'opha_transfer_chunks' => { 
      inventory => 500, 
      nodes => 500, 
      events => 500, 
      status => 500, 
      latest_data => 500, 
    },


By default, all the data types are enabled, so all the data types are being synchronised (nodes, inventory, events, latest_data and status).

The synchronisation is configured in a cron job, that is going to run /usr/local/omk/bin/opha-cli.pl act=pull. For debugging purposes, you can run the same script with the following parameters:

bin/opha-cli.pl act=pull data_types=inventory,nodes,events,status,latest_data debug=true


And using force=true to bring all the data again, not only the data modified or created since the last synchronisation. 

You should see something like this when the script es finished:

[Tue May 14 15:32:31 2019] [debug]   [ fulla ]
[Tue May 14 15:32:31 2019] [debug] * inventory took: 0.89 sec - 109 results
[Tue May 14 15:32:31 2019] [debug] * nodes took: 0.87 sec - 0 results
[Tue May 14 15:32:31 2019] [debug] * events took: 0.87 sec - 52 results
[Tue May 14 15:32:31 2019] [debug] * status took: 0.87 sec - 200 results
[Tue May 14 15:32:31 2019] [debug] * latest_data took: 0.96 sec - 438 results
[Tue May 14 15:32:31 2019] [debug]   [ poller-nine ]
[Tue May 14 15:32:31 2019] [debug] * inventory took: 4.26 sec - 434 results
[Tue May 14 15:32:31 2019] [debug] * nodes took: 2.88 sec - 0 results
[Tue May 14 15:32:31 2019] [debug] * events took: 3.75 sec - 5000 results
[Tue May 14 15:32:31 2019] [debug] * status took: 2.5 sec - 76 results
[Tue May 14 15:32:31 2019] [debug] * latest_data took: 17.68 sec - 18487 results

  • No labels