DIRACGrid · chrisburr · Jan 14, 2025 · Jan 14, 2025 · Jan 14, 2025
@@ -31,8 +31,8 @@ jobs:
       matrix:
         # TEST_NAME is a dummy variable used to make it easier to read the web interface
         include:
-          - TEST_NAME: "MariaDB 11.4, elasticsearch:7.9.1"
-            ARGS: MYSQL_VER=mariadb:11.4.3 ES_VER=elasticsearch:7.9.1
+          - TEST_NAME: "MariaDB 11.4"
+            ARGS: MYSQL_VER=mariadb:11.4.3
           - TEST_NAME: "HTTPS"
             ARGS: TEST_HTTPS=Yes
           - TEST_NAME: "Force DEncode"
@@ -72,8 +72,8 @@ jobs:
       run: ./integration_tests.py test-client || touch client-tests-failed
     - name: Pilot tests
       run: ./integration_tests.py test-pilot || touch pilot-tests-failed
-    - name: Elasticsearch logs
-      run: docker logs elasticsearch
+    - name: Opensearch logs
+      run: docker logs opensearch
     - name: Check test status
       run: |
         has_error=0

@@ -6,12 +6,12 @@ A running example of this dashboard can be found on the LHCb grafana organisatio
 - Production Jobs By Final Minor Status (MySQL)
 - User Jobs By Final Minor Status (MySQL)
 - Job CPU Efficiency By Job Type (MySQL)
-- User Jobs By Job Type (ElasticSearch)
+- User Jobs By Job Type (OpenSearch)
 - User Jobs By Final Minor Status (MySQL)
 - Pilots By Status (MySQL)
 
 ## How to import this dashboard into another Grafana installation?
-- Create Grafana data sources for the MySQL database and ElasticSearch cluster (both the DIRAC certification versions).
+- Create Grafana data sources for the MySQL database and OpenSearch cluster (both the DIRAC certification versions).
 - Create a new dashboard and in 'Dashboard settings' under 'JSON model' replace the JSON representation of the dashboard with this one.
 - In the JSON file, replace the datasource uid's with the ones for the data sources in your grafana installation. You can find the UID of a data source:
     - with the [API](https://grafana.com/docs/grafana/latest/developers/http_api/data_source/)

@@ -38,17 +38,13 @@ generic connection details can be applied in CS location below (the shown values
    }
 
 
-ElasticSearch versions
-----------------------
+OpenSearch versions
+-------------------
 
-ElasticSearch is an optional dependency for DIRAC servers installations. Supported versions:
+OpenSearch is a non-optional dependency for DIRAC servers installations.
+OpenSearch server is not shipped with DIRAC. You are responsible of its administration.
 
-- 7.x up until 7.13
-- OpenDistro and OpenSearch releases "compatible" with the above ElasticSearch versions.
-
-ElasticSearch server is not shipped with DIRAC. You are responsible of its administration.
-
-You can run your ES cluster without authentication, or using User name and password, or using certificates. You may add the following parameters:
+You can run your OpenSearch cluster without authentication, or using User name and password, or using certificates. You may add the following parameters:
 
   - ``User`` (default:``''``)
   - ``Password`` (default:``''``)

@@ -62,7 +62,7 @@ Logstash and ELK configurations
 
 The suggested logstash configuration (``/etc/logstash/conf.d/configname``) can be found in https://gitlab.cern.ch/ai/it-puppet-module-dirac/-/blob/qa/code/templates/logstash.conf.erb (check the `full documentation <https://opensearch.org/docs/latest/clients/logstash/index/>`_)
 
-The ElasticSearch template ``lhcb-dirac-logs_default`` looks like::
+The OpenSearch template ``lhcb-dirac-logs_default`` looks like::
 
   {
     "order": 1,

@@ -158,7 +158,7 @@ dirac-json.conf (Add all needed components and choose the output you want)::
   [SERVICE] where we describe our json parser (from dirac Json log backend)
   [INPUT] where we describe dirac components log file and the way it will be parsed (json)
   [FILTER] where we apply modifications to parsed data, for example adding a levelname "DEV" whenever logs are not well formatted, typically "print" in code, or adding fields like hostname to know from which host logs are coming, but also more complex treatments like in dirac.lua script (described later)
-  [OUTPUT] where we describe formatted logs destination, here, we have stdout, files on disks and elasticsearch.
+  [OUTPUT] where we describe formatted logs destination, here, we have stdout, files on disks and opensearch.
 
 dirac-parsers.conf::
 
@@ -203,19 +203,19 @@ dirac.lua::
 Testing
 -------
 
-Before throwing logs to ElasticSearch, config can be tested in Standard output by uncommenting::
+Before throwing logs to OpenSearch, config can be tested in Standard output by uncommenting::
 
   [OUTPUT]
       name             stdout
       match            *
 
-...and commenting ElasticSearch outputs.
+...and commenting OpenSearch outputs.
 
 Then by using command::
 
   /opt/fluent-bit/bin/fluent-bit -c //etc/fluent-bit/fluent-bit.conf
 
-NOTE: When all is OK, uncomment ElasticSearch outputs and comment stdout output
+NOTE: When all is OK, uncomment OpenSearch outputs and comment stdout output
 
 Service
 -------

@@ -6,4 +6,4 @@ The Framework/monitoring service
 
 The framework system for the monitoring of services and agents has been removed and will no longer be used.
 
-It has been replaced by an ElasticSearch-based monitoring system. You can read about it in :ref:`Monitoring <monitoring_system>`
+It has been replaced by an OpenSearch-based monitoring system. You can read about it in :ref:`Monitoring <monitoring_system>`
@@ -20,19 +20,18 @@ The Monitoring system is used to monitor various components of DIRAC. Currently,
   - PilotSubmission Monitoring: for monitoring the DIRAC pilot submission statistics from SiteDirector agents.
   - DataOperation Monitoring: for monitoring the DIRAC data operation statistics as well as individual failures from interactive use of ``StorageElement``.
 
-It is based on Elasticsearch (OpenSearch) distributed search and analytics NoSQL database.
-If you want to use it, you have to install the Monitoring service, and of course connect to a ElasticSearch instance.
+It is based on OpenSearch distributed search and analytics NoSQL database.
+If you want to use it, you have to install the Monitoring service, and of course connect to a OpenSearch instance.
 
-Install Elasticsearch/OpenSearch
-================================
+Install OpenSearch
+==================
 
-This is not covered here, as installation and administration of ES are not part of DIRAC guide.
-Just a note on the ES versions supported: only ES7+ versions are currently supported, and are later to be replaced by OpenSearch services.
+This is not covered here.
 
 Configure the MonitoringSystem
 ===============================
 
-You can run your Elastic/OpenSearch cluster even without authentication, or using User name and password. You have to add the following parameters:
+You can run your OpenSearch cluster even without authentication, or using User name and password. You have to add the following parameters:
 
   - User
   - Password
@@ -82,7 +81,7 @@ The given periods above are also the default periods in the code.
 Enable the Monitoring System
 ============================
 
-In order to enable the monitoring of all the following types with an ElasticSearch-based backend, you should add the value `Monitoring` to the flag
+In order to enable the monitoring of all the following types with an OpenSearch-based backend, you should add the value `Monitoring` to the flag
 `MonitoringBackends/Default` in the Operations section of the CS.
 If you want to override this flag for a specific type, say, you want to only have Monitoring (and no Accounting) for WMSHistory, you just create a flag `WMSHistory` set to `Monitoring`.
 If, for example, you want both Monitoring and Accounting for WMSHistory (but not for other types), you set `WMSHistory = Accounting, Monitoring`. If no flag is set for `WMSHistory`, the `Default` flag will be used.
@@ -111,7 +110,7 @@ This can be done either via the CS or directly in the web app in the Configurati
 WMSHistory & PilotsHistory Monitoring
 =====================================
 
-The WorkloadManagement/StatesAccountingAgent creates, every 15 minutes, a snapshot with the contents of JobDB and PilotAgentsDB and sends it to an Elasticsearch-based database.
+The WorkloadManagement/StatesAccountingAgent creates, every 15 minutes, a snapshot with the contents of JobDB and PilotAgentsDB and sends it to an OpenSearch-based database.
 This same agent can also report the WMSHistory to the MySQL backend used by the Accounting system (which is in fact the default).
 
 Optionally, you can use an MQ system (like ActiveMQ) for failover, even though the agent already has a simple failover mechanism.
@@ -169,12 +168,12 @@ Accessing the Monitoring information
 
 After you installed and configured the Monitoring system, you can use the Monitoring web application for the types WMSHistory and RMS.
 
-However, every type can directly be monitored in Kibana dashboards that can be imported into your Elasticsearch (or Opensearch) instance. You can find and import these dashboards from DIRAC/dashboards as per the following example.
+However, every type can directly be monitored in Kibana dashboards that can be imported into your Opensearch instance. You can find and import these dashboards from DIRAC/dashboards as per the following example.
 Grafana dashboards are also provided for some of the types.
 
 *Kibana dashboard for WMSHistory*
   A dashboard for WMSHistory monitoring ``WMSDashboard`` is available `here <https://github.com/DIRACGrid/DIRAC/tree/integration/dashboards/WMS>`__ for import as a NDJSON (as support for JSON is being removed in the latest versions of Kibana).
-  The dashboard may not be compatible with older versions of ElasticSearch.
+  The dashboard may not be compatible with older versions of OpenSearch.
   To import it in the Kibana UI, go to Management -> Saved Objects -> Import and import the JSON file.
 
   Note: the JSON file already contains the index patterns needed for the visualizations. You may need to adapt the index patterns to your existing ones.
@@ -74,12 +74,8 @@ All these agents are necessary for the WMS, and each of them should be installed
 You can duplicate some of these agents as long as you provide the correct configuration.
 A typical example is the SiteDirector, for which you may want to deploy even 1 for each of the sites managed.
 
-Optional agents are:
-
-StatesAccountingAgent or StatesMonitoringAgent
-  Use one or the other.
-  StatesMonitoringAgent is used for producing Monitoring plots through the :ref:`Monitoring System <monitoring_system>`. (so, using ElasticSearch as backend),
-  while StatesAccountingAgent does the same job but using the Accounting system (so, MySQL as backend).
+StatesAccountingAgent.
+  Used for producing Monitoring plots through the :ref:`Monitoring System <monitoring_system>`, or using the Accounting system (so, MySQL as backend).
 
 A very different type of agent is the *JobAgent*, which is run by the pilot jobs and should NOT be run in a server installation.
 

@@ -3,7 +3,7 @@ Developing Databases
 ====================
 
 This is a quick guide about developing classes interacting with MySQL databases.
-DIRAC supports also Elasticsearch/OpenSearch NoSQL database, but it is not part of this document.
+DIRAC supports also OpenSearch NoSQL database, but it is not part of this document.
 
 Before starting developing databases, you have to make sure that MySQL is installed, as well as python-mysql,
 as explained in :ref:`editing_code`, and make sure that MySQL service is on.

@@ -53,28 +53,28 @@ Parameters
 +-----------+------------------------------------------------------------------+----------------------+
 
 
-ElasticSearchBackend
+OpenSearch Backend
 --------------------
 
 Description
 ~~~~~~~~~~~
-Used to emit log records in the an ElasticSearch database.
+Used to emit log records in the an OpenSearch database.
 The *Backend* acccepts logs from *Debug* to *Always* level.
 
 Parameters
 ~~~~~~~~~~
 +-----------+------------------------------------------------------------------+----------------------+
 | Option    | Description                                                      | Default value        |
 +===========+==================================================================+======================+
-| Host      | host machine where the ElasticSearch DB is installed             | ''                   |
+| Host      | host machine where the OpenSearch DB is installed                | ''                   |
 +-----------+------------------------------------------------------------------+----------------------+
-| Port      | port where the ElasticSearch DB listen                           | 9203                 |
+| Port      | port where the OpenSearch DB listen                              | 9203                 |
 +-----------+------------------------------------------------------------------+----------------------+
-| User      | username of the ElasticSearch DB   (optional)                    | None                 |
+| User      | username of the OpenSearch DB   (optional)                       | None                 |
 +-----------+------------------------------------------------------------------+----------------------+
-| Password  | password of the ElasticSearch DB   (optional)                    | None                 |
+| Password  | password of the OpenSearch DB   (optional)                       | None                 |
 +-----------+------------------------------------------------------------------+----------------------+
-| Index     | ElasticSearch index                                              | ''                   |
+| Index     | OpenSearch index                                                 | ''                   |
 +-----------+------------------------------------------------------------------+----------------------+
 | BufferSize| maximum size of the buffer before sending                        | 1000                 |
 +-----------+------------------------------------------------------------------+----------------------+

@@ -761,7 +761,7 @@ To summarize, this file configures two agents respectively named *SimplestAgent*
 In *SimplestAgent*, it sets the level of *gLogger* at *info*, adds 5 *Backend* objects to it, which
 are *stdout*, *stderr*, two *file Backend* objects and an *ElastiSearch* access. Thus, each log record superior to
 *info* level, created by a *Logging* object in the agent, will be sent
-to 5 different outputs: *stdout*, *stderr*, */tmp/logtmp.log*, */tmp/logtmp2.log* and ElasticSearch. In *AnotherAgent*, the same process is performed, and each log record superior to *notice* level is sent to *stdout* and another ElasticSearch database because of the redifinition. None of the default *Backend* objects of the *Operations* section are used because of the overwriting.
+to 5 different outputs: *stdout*, *stderr*, */tmp/logtmp.log*, */tmp/logtmp2.log* and OpenSearch. In *AnotherAgent*, the same process is performed, and each log record superior to *notice* level is sent to *stdout* and another OpenSearch database because of the redifinition. None of the default *Backend* objects of the *Operations* section are used because of the overwriting.
 In addition, the log records will be not displayed with color.
 
 Summary of the command line argument configuration

@@ -248,7 +248,7 @@ Continuous Integration software
 -------------------------------
 
 There are several tools, on the free market, for so-called *Continuous Integration*, or simply CI_.
-One possibility is to use Jenkins, but today (from branch *rel-v7r0*) all DIRAC integration tests are run
+One possibility is to use Jenkins, but all DIRAC integration tests are run
 by `GitHub Actions <https://github.com/DIRACGrid/DIRAC/actions?query=workflow%3A%22Integration+tests%22>`_
 
 If you have looked in the `DIRAC/tests <https://github.com/DIRACGrid/DIRAC/tree/integration/tests>`_
@@ -273,7 +273,7 @@ What can you do with those above? You can run the Integration tests you read abo
 How do I do that?
 
 - you need a MySQL DB somewhere, empty, to be used only for testing purposes (in GitHub Actions and GitLab-CI a docker container is instantiated for the purpose)
-- you need a ElasticSearch instance running somewhere, empty, to be used only for testing purposes (in GitHub Actions and GitLab-CI a docker container is instantiated for the purpose)
+- you need a OpenSearch instance running somewhere, empty, to be used only for testing purposes (in GitHub Actions and GitLab-CI a docker container is instantiated for the purpose)
 - if you have tests that need to access other DBs, you should also have them ready, again used for testing purposes.
 
 The files ``DIRAC/tests/Integration/all_integration_client_tests.sh`` and ``DIRAC/tests/Integration/all_integration_server_tests.sh``

@@ -111,6 +111,6 @@ The MonitoringUtilities module provides the functionality needed to store or del
 Dynamic Component Monitoring
 ============================
 
-This system takes care of managing monitoring information of DIRAC component. It is based on ElasticSearch database. It is based on MonitoringSystem.
+This system takes care of managing monitoring information of DIRAC component. It is based on OpenSearch.
 The information is collected by the __storeProfiling periodic task on the SystemAdministartor. The task is disabled by default.
 The MonitoringReporter is used to propagate the DB whith the collected values.
@@ -14,7 +14,7 @@ The system is storing monitoring information. It means the data stored in the da
    -computing infrastructures (for example: machines, etc.)
    -data movement (for example: Data operation etc.)
 
-This system is based on ElasticSearch.
+This system is based on OpenSearch.
 
 ------------
 Architecture
@@ -30,9 +30,9 @@ It is based on layered architecture and is based on DIRAC architecture:
 * **DB**
 
   * MonitoringDB:
-    It is a based on ElasticSearch database and provides all the methods which needed to create the reports. Currently, it supports only
+    It is a based on OpenSearch database and provides all the methods which needed to create the reports. Currently, it supports only
     one type of query: It creates a dynamic buckets which will be used to retrieve the data points. The query used to retrieve the data points
-    is retrieveBucketedData. As you can see it uses the ElasticSearch QueryDSL language. Before you modify this method please learn this language.
+    is retrieveBucketedData. As you can see it uses the OpenSearch QueryDSL language. Before you modify this method please learn this language.
 
    * private:
       - Plotters: It contains all Plotters used to create the plots. More information will be provided later.

@@ -1198,10 +1198,10 @@ def _make_config(modules, flags, release_var, editable):
         "DB_ROOTPWD": DB_ROOTPWD,
         "DB_HOST": DB_HOST,
         "DB_PORT": DB_PORT,
-        # ElasticSearch settings
+        # OpenSearch settings
         "NoSQLDB_USER": "elastic",
         "NoSQLDB_PASSWORD": "changeme",
-        "NoSQLDB_HOST": "elasticsearch",
+        "NoSQLDB_HOST": "opensearch",
         "NoSQLDB_PORT": "9200",
         # IAM initial settings
         "IAM_INIT_CLIENT_ID": IAM_INIT_CLIENT_ID,

@@ -1,5 +1,5 @@
 """ MySQL based WMSHistory accounting.
-    It's suggested to replace this with the ElasticSearch based WMSHistory monitoring.
+    It's suggested to replace this with the OpenSearch based WMSHistory monitoring.
 
     Filled by the agent "WorkloadManagement/StatesAccountingAgent"
 """
Original file line number	Diff line number	Diff line change
Expand Up		@@ -6,4 +6,4 @@ The Framework/monitoring service

		The framework system for the monitoring of services and agents has been removed and will no longer be used.

		It has been replaced by an ElasticSearch-based monitoring system. You can read about it in :ref:`Monitoring <monitoring_system>`
		It has been replaced by an OpenSearch-based monitoring system. You can read about it in :ref:`Monitoring <monitoring_system>`