From 24693c75ceec3a28c35a0bf634c4e22cff6d83b5 Mon Sep 17 00:00:00 2001 From: sbasu96 Date: Mon, 17 Jun 2024 16:28:23 +0530 Subject: [PATCH 01/11] Updating documentation Signed-off-by: Basu --- docs/source/Upgrade/index.rst | 4 ++++ docs/source/Upgrade/restore_telemetryDB.rst | 6 ++++++ docs/source/Upgrade/upgrade.rst | 4 +++- 3 files changed, 13 insertions(+), 1 deletion(-) create mode 100644 docs/source/Upgrade/restore_telemetryDB.rst diff --git a/docs/source/Upgrade/index.rst b/docs/source/Upgrade/index.rst index 3a23471a4..ee8c0ab7a 100644 --- a/docs/source/Upgrade/index.rst +++ b/docs/source/Upgrade/index.rst @@ -34,5 +34,9 @@ Once the cloning process is done, follow the steps listed below to invoke the up - In Omnia v1.5.1 OpenLDAP client configuration was supported. If you had configured OpenLDAP client to external enterprise LDAP server in Omnia v1.5.1, then this configuration will not be restored during upgrade. In Omnia v1.6, Omnia installs OpenLDAP server and the user needs to reconfigure the OpenLDAP server to integrate it with an external LDAP server. - The slurm setup in Omnia v1.5.1 cluster is upgraded to configless slurm in v1.6. + * While the Omnia upgrade process does attempt an automatic backup of the Telemetry database, it is recommended to manually create a backup before initiating the upgrade for added precaution. After the upgrade, the restoration of the telemetry database must be performed manually by the user. + + + .. caution:: The NFS share directory mentioned in ``omnia_usrhome_share``, provided in v1.5.1 ``omnia_config.yml``, is unmounted from the cluster and deleted from the head node, along with all the user data while executing the ``prepare_upgrade.yml`` playbook. Hence, it is recommended that you take a backup of the Omnia NFS share before executing the ``prepare_upgrade.yml`` playbook. \ No newline at end of file diff --git a/docs/source/Upgrade/restore_telemetryDB.rst b/docs/source/Upgrade/restore_telemetryDB.rst new file mode 100644 index 000000000..2a7976ba0 --- /dev/null +++ b/docs/source/Upgrade/restore_telemetryDB.rst @@ -0,0 +1,6 @@ +Restoring Telemetry database +============================= + +After upgrading Omnia, manually restore the telemetry database if automatic restoration does not occur. Perform the following steps: + +1. \ No newline at end of file diff --git a/docs/source/Upgrade/upgrade.rst b/docs/source/Upgrade/upgrade.rst index b609a5a9c..178b57d10 100644 --- a/docs/source/Upgrade/upgrade.rst +++ b/docs/source/Upgrade/upgrade.rst @@ -12,4 +12,6 @@ To execute the ``upgrade.yml`` playbook, run the following command: :: Where inventory refers to the auto-generated inventory file in Omnia v1.6 format. -This is the final step, and once the upgrade.yml playbook is executed successfully, the upgrade process is complete! \ No newline at end of file +This is the final step, and once the upgrade.yml playbook is executed successfully, the upgrade process is complete! + +Optional - `Restore Telemetry database post upgrade `_ \ No newline at end of file From fb8b0fbbbd4839c65ce8fd78baceb3d7d496cd8b Mon Sep 17 00:00:00 2001 From: sbasu96 Date: Mon, 17 Jun 2024 19:03:49 +0530 Subject: [PATCH 02/11] Updating documentation Signed-off-by: Basu --- docs/source/Upgrade/restore_telemetryDB.rst | 46 +++++++++++++++++++-- 1 file changed, 42 insertions(+), 4 deletions(-) diff --git a/docs/source/Upgrade/restore_telemetryDB.rst b/docs/source/Upgrade/restore_telemetryDB.rst index 2a7976ba0..87e00cf12 100644 --- a/docs/source/Upgrade/restore_telemetryDB.rst +++ b/docs/source/Upgrade/restore_telemetryDB.rst @@ -1,6 +1,44 @@ -Restoring Telemetry database -============================= +Restoring Telemetry database post Omnia upgrade +================================================ -After upgrading Omnia, manually restore the telemetry database if automatic restoration does not occur. Perform the following steps: +After upgrading Omnia, if you want to retain the telemetry data from Omnia v1.5.1, you need to manually restore the telemetry database from the ``backup_location`` configured in `upgrade_config,yml `_. Perform the following steps to do so: -1. \ No newline at end of file +1. Copy the backed up telemetry database from the ``backup_location`` configured in ``upgrade_config,yml`` to ``/opt/omnia/telemetry/iDRAC-Referencing-Tools``. + +2. Stop the Omnia telemetry services on all the cluster nodes. + +3. In order to execute the psql commands, connect to the ``timescaledb`` pod using the following steps: + + * Execute the following command: :: + + kubectl exec -it timescaledb-0 -n telemetry-and-visualizations -- /bin/bash + + * Verify that the dump file is present using the ``ls`` command. + +4. Now, connect to the ``telemetry_metrics`` database using the following command: :: + + psql -U omnia + +5. Execute the following command to obtain the ``pod_external_ip`` for the timescale database: :: + + kubectl get svc -A output + +6. Execute the following command to initiate the database restore operation: :: + + psql --dbname=telemetry_metrics --host= --port=5432 --username=omnia --file=telemetry_tsdb_dump.sql < telemetry_tsdb_dump.sql + + +Next steps +============ + +1. Use the following command to see and verify the restored data: :: + + timescaledb-0:/go/src/github.com/telemetry-reference-tools# psql -U omnia + +2. Restart the Omnia telemetry services on all the cluster nodes. + +3. Check and see if the number of rows have increased in the timescale database. This signifies that the restoration has taken place successfully. + +4. Check the status both ``omnia_telemtry.service`` and public ``time_series`` metrics. + +5. Restart the node. \ No newline at end of file From 119d1a5738007063173a0c106432a803876e490e Mon Sep 17 00:00:00 2001 From: sbasu96 Date: Mon, 17 Jun 2024 19:10:57 +0530 Subject: [PATCH 03/11] Updating documentation Signed-off-by: Basu --- docs/source/Upgrade/restore_telemetryDB.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/Upgrade/restore_telemetryDB.rst b/docs/source/Upgrade/restore_telemetryDB.rst index 87e00cf12..27d4ba444 100644 --- a/docs/source/Upgrade/restore_telemetryDB.rst +++ b/docs/source/Upgrade/restore_telemetryDB.rst @@ -1,7 +1,7 @@ Restoring Telemetry database post Omnia upgrade ================================================ -After upgrading Omnia, if you want to retain the telemetry data from Omnia v1.5.1, you need to manually restore the telemetry database from the ``backup_location`` configured in `upgrade_config,yml `_. Perform the following steps to do so: +After upgrading Omnia, if you want to retain the telemetry data from Omnia v1.5.1, you need to manually restore the telemetry database from the ``backup_location`` configured while executing the `prepare_config.yml `_ playbook. Perform the following steps to do so: 1. Copy the backed up telemetry database from the ``backup_location`` configured in ``upgrade_config,yml`` to ``/opt/omnia/telemetry/iDRAC-Referencing-Tools``. From 40362703dc63dec9b781040588f5b0ea709dc950 Mon Sep 17 00:00:00 2001 From: sbasu96 Date: Tue, 18 Jun 2024 11:47:35 +0530 Subject: [PATCH 04/11] Updating documentation Signed-off-by: Basu --- docs/source/Upgrade/prepare_config.rst | 6 ++- docs/source/Upgrade/restore_telemetryDB.rst | 55 ++++++++++++++------- 2 files changed, 43 insertions(+), 18 deletions(-) diff --git a/docs/source/Upgrade/prepare_config.rst b/docs/source/Upgrade/prepare_config.rst index 9158cc037..a4e98e22c 100644 --- a/docs/source/Upgrade/prepare_config.rst +++ b/docs/source/Upgrade/prepare_config.rst @@ -7,6 +7,9 @@ This is the first step of upgrade process and uses the ``prepare_config.yml`` pl * Generates the inventory for Omnia v1.6 from the v1.5.1 inventory. * Sets the Omnia v1.6 execution environment by updating the ansible and python versions compatible to v1.6. * Creates backup of the Omnia v1.5.1 database. + * Creates a backup of the Omnia v1.5.1 telemetry database if the ``timescaledb`` pod is in ``running`` state. + +.. note:: Post upgrade, restoring the Omnia telemetry database in Omnia v1.6 is completely manual and user-driven. Before executing ``prepare_config.yml``, user needs to update ``upgrade_config.yml`` with the following details: @@ -30,7 +33,8 @@ Expected output of this playbook execution: * Auto-populated Omnia v1.6 configuration files in the ``/omnia/input``. * Auto-generated inventory file in Omnia v1.6 format. This is available in the ``/omnia/upgrade`` folder and will be used later during the execution of `upgrade.yml `_. - * Backup of the omnia v1.5.1 database is created at the ``backup_location`` specified in the ``upgrade_config.yml``. The backup file is named as ``backup.sql``. + * Backup of the Omnia v1.5.1 database is created at the ``backup_location`` specified in the ``upgrade_config.yml``. The backup file is named as ``backup.sql``. + * Backup of the Omnia v1.5.1 telemetry database is created at the ``backup_location`` specified in the ``upgrade_config.yml``. The backup file is named as ``telemetry_tsdb_dump.sql``. **Review or Update the auto-generated config files** diff --git a/docs/source/Upgrade/restore_telemetryDB.rst b/docs/source/Upgrade/restore_telemetryDB.rst index 27d4ba444..657668ea6 100644 --- a/docs/source/Upgrade/restore_telemetryDB.rst +++ b/docs/source/Upgrade/restore_telemetryDB.rst @@ -3,11 +3,14 @@ Restoring Telemetry database post Omnia upgrade After upgrading Omnia, if you want to retain the telemetry data from Omnia v1.5.1, you need to manually restore the telemetry database from the ``backup_location`` configured while executing the `prepare_config.yml `_ playbook. Perform the following steps to do so: -1. Copy the backed up telemetry database from the ``backup_location`` configured in ``upgrade_config,yml`` to ``/opt/omnia/telemetry/iDRAC-Referencing-Tools``. +1. Copy the backed up telemetry database file, that is ``telemetry_tsdb_dump.sql``, from the ``backup_location`` to ``/opt/omnia/telemetry/iDRAC-Referencing-Tools``. -2. Stop the Omnia telemetry services on all the cluster nodes. +2. Stop the Omnia telemetry services on all the cluster nodes. Run the ``telemetry.yml`` playbook after setting the ``idrac_telemetry_support``, ``omnia_telemetry_support``, and ``visualization_support`` parameters to ``false`` in ``input/telemetry_config.yml``. Execute the following command: :: -3. In order to execute the psql commands, connect to the ``timescaledb`` pod using the following steps: + cd telemetry + ansible-playbook telemetry.yml -i ../upgrade/inventory + +3. Connect to the ``timescaledb`` pod and execute the psql commands. Perform the following steps: * Execute the following command: :: @@ -15,30 +18,48 @@ After upgrading Omnia, if you want to retain the telemetry data from Omnia v1.5. * Verify that the dump file is present using the ``ls`` command. -4. Now, connect to the ``telemetry_metrics`` database using the following command: :: + * Connect to the psql client using the following command: :: - psql -U omnia + psql -U -5. Execute the following command to obtain the ``pod_external_ip`` for the timescale database: :: + where "timescaledb_user" is the configured ``timescaledb`` user name. - kubectl get svc -A output + * Drop the current database using the command below: :: -6. Execute the following command to initiate the database restore operation: :: + DROP DATABASE telemetry_metrics; - psql --dbname=telemetry_metrics --host= --port=5432 --username=omnia --file=telemetry_tsdb_dump.sql < telemetry_tsdb_dump.sql + .. note:: If there are processes which is preventing you to drop the database, then terminate those processes and try again. + * Create an empty telemetry database for Omnia v1.6 using the command below: :: -Next steps -============ + CREATE DATABASE telemetry_metrics; + + * Exit from the psql client using ``\q`` command. + + * Execute the following command to initiate the database restore operation: :: + + psql --dbname=telemetry_metrics --host= --port=5432 --username= -v ON_ERROR_STOP=1 --echo-errors -c "SELECT public.timescaledb_pre_restore();" -f telemetry_tsdb_dump.sql -c "SELECT public.timescaledb_post_restore();" -1. Use the following command to see and verify the restored data: :: + .. note:: Execute the following command to obtain the ``pod_external_ip`` and ``port`` for the ``timescaledb`` pod: :: - timescaledb-0:/go/src/github.com/telemetry-reference-tools# psql -U omnia + kubectl get svc -A output + + * Drop the ``insert_block_trigger`` if it exists using the following commands: :: + + Psql -U omnia + \c telemetry_metrics + DROP TRIGGER ts_insert_blocker ON public.timeseries_metrics; + DROP TRIGGER ts_insert_blocker ON omnia_telemetry.metrics; + + +Next steps +============ -2. Restart the Omnia telemetry services on all the cluster nodes. +1. Connect to the ``telemetry_metrics`` database and verify if the restored telemetry data is present in ``public.timeseries_metrics`` and ``omnia_telemtry.metrics`` tables. -3. Check and see if the number of rows have increased in the timescale database. This signifies that the restoration has taken place successfully. +2. Post verification, you can choose to restart the Omnia telemetry services. Run the ``telemetry.yml`` playbook after modifying the ``input/telemetry_config.yml`` as per your requirements. For more information regarding the telemetry parameters, `click here <../InstallationGuides/BuildingClusters/schedulerinputparams.html#id18>`_. Execute the following command: :: -4. Check the status both ``omnia_telemtry.service`` and public ``time_series`` metrics. + cd telemetry + ansible-playbook telemetry.yml -i ../upgrade/inventory -5. Restart the node. \ No newline at end of file +3. After telemetry services are enabled, check ``omnia_telemtry.metrics`` and ``public.timeseries_metrics`` tables to see if the number of rows have increased. This signifies that the fresh telemetry data from Omnia v1.6 is getting updated in the database. \ No newline at end of file From fac89cb9876d086b8c06dc2ef5db4d52d4419662 Mon Sep 17 00:00:00 2001 From: sbasu96 Date: Tue, 18 Jun 2024 11:59:26 +0530 Subject: [PATCH 05/11] Updating documentation Signed-off-by: Basu --- docs/source/Upgrade/restore_telemetryDB.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/source/Upgrade/restore_telemetryDB.rst b/docs/source/Upgrade/restore_telemetryDB.rst index 657668ea6..4e3cfb61a 100644 --- a/docs/source/Upgrade/restore_telemetryDB.rst +++ b/docs/source/Upgrade/restore_telemetryDB.rst @@ -1,7 +1,7 @@ Restoring Telemetry database post Omnia upgrade ================================================ -After upgrading Omnia, if you want to retain the telemetry data from Omnia v1.5.1, you need to manually restore the telemetry database from the ``backup_location`` configured while executing the `prepare_config.yml `_ playbook. Perform the following steps to do so: +After upgrading Omnia, if you want to retain the telemetry data from Omnia v1.5.1, you need to manually restore the telemetry database from the ``telemetry_tsdb_dump.sql`` file. Perform the following steps to do so: 1. Copy the backed up telemetry database file, that is ``telemetry_tsdb_dump.sql``, from the ``backup_location`` to ``/opt/omnia/telemetry/iDRAC-Referencing-Tools``. @@ -24,15 +24,15 @@ After upgrading Omnia, if you want to retain the telemetry data from Omnia v1.5. where "timescaledb_user" is the configured ``timescaledb`` user name. - * Drop the current database using the command below: :: + * Drop the current database using the command below: :: - DROP DATABASE telemetry_metrics; + DROP DATABASE telemetry_metrics; .. note:: If there are processes which is preventing you to drop the database, then terminate those processes and try again. - * Create an empty telemetry database for Omnia v1.6 using the command below: :: + * Create an empty telemetry database for Omnia v1.6 using the command below: :: - CREATE DATABASE telemetry_metrics; + CREATE DATABASE telemetry_metrics; * Exit from the psql client using ``\q`` command. @@ -46,7 +46,7 @@ After upgrading Omnia, if you want to retain the telemetry data from Omnia v1.5. * Drop the ``insert_block_trigger`` if it exists using the following commands: :: - Psql -U omnia + psql -U omnia \c telemetry_metrics DROP TRIGGER ts_insert_blocker ON public.timeseries_metrics; DROP TRIGGER ts_insert_blocker ON omnia_telemetry.metrics; From 4de07512b8b0aa0046785b53db50c3ef9946e46d Mon Sep 17 00:00:00 2001 From: sbasu96 Date: Tue, 18 Jun 2024 12:20:11 +0530 Subject: [PATCH 06/11] Updating documentation Signed-off-by: Basu --- docs/source/Upgrade/restore_telemetryDB.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/source/Upgrade/restore_telemetryDB.rst b/docs/source/Upgrade/restore_telemetryDB.rst index 4e3cfb61a..6107870cd 100644 --- a/docs/source/Upgrade/restore_telemetryDB.rst +++ b/docs/source/Upgrade/restore_telemetryDB.rst @@ -22,13 +22,13 @@ After upgrading Omnia, if you want to retain the telemetry data from Omnia v1.5. psql -U - where "timescaledb_user" is the configured ``timescaledb`` user name. + where "timescaledb_user" is the configured ``timescaledb`` username for telemetry. * Drop the current database using the command below: :: DROP DATABASE telemetry_metrics; - .. note:: If there are processes which is preventing you to drop the database, then terminate those processes and try again. + .. note:: If there are processes which is preventing you to drop the database, then terminate those processes and try again. * Create an empty telemetry database for Omnia v1.6 using the command below: :: @@ -40,7 +40,7 @@ After upgrading Omnia, if you want to retain the telemetry data from Omnia v1.5. psql --dbname=telemetry_metrics --host= --port=5432 --username= -v ON_ERROR_STOP=1 --echo-errors -c "SELECT public.timescaledb_pre_restore();" -f telemetry_tsdb_dump.sql -c "SELECT public.timescaledb_post_restore();" - .. note:: Execute the following command to obtain the ``pod_external_ip`` and ``port`` for the ``timescaledb`` pod: :: + .. note:: Execute the following command to obtain the ``pod_external_ip`` and ``port`` for the ``timescaledb`` pod: :: kubectl get svc -A output @@ -55,7 +55,7 @@ After upgrading Omnia, if you want to retain the telemetry data from Omnia v1.5. Next steps ============ -1. Connect to the ``telemetry_metrics`` database and verify if the restored telemetry data is present in ``public.timeseries_metrics`` and ``omnia_telemtry.metrics`` tables. +1. Connect to the ``telemetry_metrics`` database and verify if the restored telemetry data is present in ``public.timeseries_metrics`` and ``omnia_telemetry.metrics`` tables. 2. Post verification, you can choose to restart the Omnia telemetry services. Run the ``telemetry.yml`` playbook after modifying the ``input/telemetry_config.yml`` as per your requirements. For more information regarding the telemetry parameters, `click here <../InstallationGuides/BuildingClusters/schedulerinputparams.html#id18>`_. Execute the following command: :: From 4b8ccf86889a0e117fa8f13f6fdd4129fc97d3d9 Mon Sep 17 00:00:00 2001 From: sbasu96 Date: Tue, 18 Jun 2024 12:26:51 +0530 Subject: [PATCH 07/11] Updating documentation Signed-off-by: Basu --- docs/source/Upgrade/restore_telemetryDB.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/source/Upgrade/restore_telemetryDB.rst b/docs/source/Upgrade/restore_telemetryDB.rst index 6107870cd..7c121cdf2 100644 --- a/docs/source/Upgrade/restore_telemetryDB.rst +++ b/docs/source/Upgrade/restore_telemetryDB.rst @@ -40,8 +40,8 @@ After upgrading Omnia, if you want to retain the telemetry data from Omnia v1.5. psql --dbname=telemetry_metrics --host= --port=5432 --username= -v ON_ERROR_STOP=1 --echo-errors -c "SELECT public.timescaledb_pre_restore();" -f telemetry_tsdb_dump.sql -c "SELECT public.timescaledb_post_restore();" - .. note:: Execute the following command to obtain the ``pod_external_ip`` and ``port`` for the ``timescaledb`` pod: :: - + .. note:: Execute the following command to obtain the ``pod_external_ip`` and ``port`` for the ``timescaledb`` pod: + :: kubectl get svc -A output * Drop the ``insert_block_trigger`` if it exists using the following commands: :: From 565bf072b0b460ba9d7a0a4a7dc43d3d6e75bfac Mon Sep 17 00:00:00 2001 From: sbasu96 Date: Tue, 18 Jun 2024 13:06:24 +0530 Subject: [PATCH 08/11] Updating documentation Signed-off-by: Basu --- docs/source/Upgrade/restore_telemetryDB.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/source/Upgrade/restore_telemetryDB.rst b/docs/source/Upgrade/restore_telemetryDB.rst index 7c121cdf2..588503719 100644 --- a/docs/source/Upgrade/restore_telemetryDB.rst +++ b/docs/source/Upgrade/restore_telemetryDB.rst @@ -28,7 +28,7 @@ After upgrading Omnia, if you want to retain the telemetry data from Omnia v1.5. DROP DATABASE telemetry_metrics; - .. note:: If there are processes which is preventing you to drop the database, then terminate those processes and try again. + .. note:: If there are processes which are preventing you to drop the database, then terminate those processes and try again. * Create an empty telemetry database for Omnia v1.6 using the command below: :: @@ -48,8 +48,8 @@ After upgrading Omnia, if you want to retain the telemetry data from Omnia v1.5. psql -U omnia \c telemetry_metrics - DROP TRIGGER ts_insert_blocker ON public.timeseries_metrics; - DROP TRIGGER ts_insert_blocker ON omnia_telemetry.metrics; + DROP TRIGGER IF EXISTS ts_insert_blocker ON public.timeseries_metrics; + DROP TRIGGER IF EXISTS ts_insert_blocker ON omnia_telemetry.metrics; Next steps From 45d02a491d1d8a4505003bbe0bedc954571e727c Mon Sep 17 00:00:00 2001 From: sbasu96 Date: Tue, 18 Jun 2024 14:41:00 +0530 Subject: [PATCH 09/11] Updating documentation Signed-off-by: Basu --- docs/source/Upgrade/index.rst | 4 ++-- docs/source/Upgrade/prepare_config.rst | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/source/Upgrade/index.rst b/docs/source/Upgrade/index.rst index ee8c0ab7a..162efecf5 100644 --- a/docs/source/Upgrade/index.rst +++ b/docs/source/Upgrade/index.rst @@ -36,7 +36,7 @@ Once the cloning process is done, follow the steps listed below to invoke the up - The slurm setup in Omnia v1.5.1 cluster is upgraded to configless slurm in v1.6. * While the Omnia upgrade process does attempt an automatic backup of the Telemetry database, it is recommended to manually create a backup before initiating the upgrade for added precaution. After the upgrade, the restoration of the telemetry database must be performed manually by the user. - - + * Omnia recommends to stop the telemetry services in Omnia v1.5.1 by configuring ``idrac_telemetry_support`` and ``omnia_telemetry_support`` to ``false`` in ``input/telemetry_config.yml``, followed by the execution of the ``telemetry.yml`` playbook before proceeding with the upgrade flow. + * For a successful restoration of the telemetry database in Omnia v1.6, ensure ``input/telemetry_config.yml`` has ``idrac_telemetry_support`` set to ``false`` and ``omnia_telemetry_support`` set to ``true``, after executing ``prepare_config.yml``. .. caution:: The NFS share directory mentioned in ``omnia_usrhome_share``, provided in v1.5.1 ``omnia_config.yml``, is unmounted from the cluster and deleted from the head node, along with all the user data while executing the ``prepare_upgrade.yml`` playbook. Hence, it is recommended that you take a backup of the Omnia NFS share before executing the ``prepare_upgrade.yml`` playbook. \ No newline at end of file diff --git a/docs/source/Upgrade/prepare_config.rst b/docs/source/Upgrade/prepare_config.rst index a4e98e22c..e74bcd047 100644 --- a/docs/source/Upgrade/prepare_config.rst +++ b/docs/source/Upgrade/prepare_config.rst @@ -9,7 +9,7 @@ This is the first step of upgrade process and uses the ``prepare_config.yml`` pl * Creates backup of the Omnia v1.5.1 database. * Creates a backup of the Omnia v1.5.1 telemetry database if the ``timescaledb`` pod is in ``running`` state. -.. note:: Post upgrade, restoring the Omnia telemetry database in Omnia v1.6 is completely manual and user-driven. +.. note:: Post upgrade, restoring the Omnia telemetry database in Omnia v1.6 is completely manual and user-driven. Omnia recommends to set ``idrac_telemetry_support`` and omnia_telemetry_support to false in input/telemetry_config.yml before executing the prepare_config.yml playbook. After prepare_config.yml has been Before executing ``prepare_config.yml``, user needs to update ``upgrade_config.yml`` with the following details: From d77bd7de3fea27dfb2a28ba1454f42f1bb67aae7 Mon Sep 17 00:00:00 2001 From: sbasu96 Date: Tue, 18 Jun 2024 14:50:00 +0530 Subject: [PATCH 10/11] Updating documentation Signed-off-by: Basu --- docs/source/Upgrade/prepare_config.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/Upgrade/prepare_config.rst b/docs/source/Upgrade/prepare_config.rst index e74bcd047..a4e98e22c 100644 --- a/docs/source/Upgrade/prepare_config.rst +++ b/docs/source/Upgrade/prepare_config.rst @@ -9,7 +9,7 @@ This is the first step of upgrade process and uses the ``prepare_config.yml`` pl * Creates backup of the Omnia v1.5.1 database. * Creates a backup of the Omnia v1.5.1 telemetry database if the ``timescaledb`` pod is in ``running`` state. -.. note:: Post upgrade, restoring the Omnia telemetry database in Omnia v1.6 is completely manual and user-driven. Omnia recommends to set ``idrac_telemetry_support`` and omnia_telemetry_support to false in input/telemetry_config.yml before executing the prepare_config.yml playbook. After prepare_config.yml has been +.. note:: Post upgrade, restoring the Omnia telemetry database in Omnia v1.6 is completely manual and user-driven. Before executing ``prepare_config.yml``, user needs to update ``upgrade_config.yml`` with the following details: From 9db65c8e7171b5779fad9515eb78fc1620f557ec Mon Sep 17 00:00:00 2001 From: sbasu96 Date: Tue, 18 Jun 2024 16:05:26 +0530 Subject: [PATCH 11/11] Updating documentation Signed-off-by: Basu --- docs/source/Upgrade/restore_telemetryDB.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/Upgrade/restore_telemetryDB.rst b/docs/source/Upgrade/restore_telemetryDB.rst index 588503719..e7c70607f 100644 --- a/docs/source/Upgrade/restore_telemetryDB.rst +++ b/docs/source/Upgrade/restore_telemetryDB.rst @@ -62,4 +62,4 @@ Next steps cd telemetry ansible-playbook telemetry.yml -i ../upgrade/inventory -3. After telemetry services are enabled, check ``omnia_telemtry.metrics`` and ``public.timeseries_metrics`` tables to see if the number of rows have increased. This signifies that the fresh telemetry data from Omnia v1.6 is getting updated in the database. \ No newline at end of file +3. After telemetry services are enabled, check ``omnia_telemetry.metrics`` and ``public.timeseries_metrics`` tables to see if the number of rows have increased. This signifies that the fresh telemetry data from Omnia v1.6 is getting updated in the database. \ No newline at end of file