Prepare Config

This is the first step of upgrade process and uses the prepare_config.yml playbook. This playbook performs the following tasks:

  • Imports the input configuration parameters from Omnia v1.5.1 and generates the input configurations for v1.6.1.

  • Generates the inventory for Omnia v1.6.1 from the v1.5.1 inventory.

  • Sets the Omnia v1.6.1 execution environment by updating the ansible and python versions compatible to v1.6.1.

  • 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.1 is completely manual and user-driven.

Before executing prepare_config.yml, user needs to update upgrade_config.yml with the following details:

Parameter

Description

old_input_location

(Required)

  • This variable points to the input directory of the old Omnia 1.5.1 installation

  • Example input location: /root/omnia15/omnia/input

backup_location

(Required)

  • This variable points to the directory where OmniaDB backups should be stored.

  • This directory must exist prior to running prepare_config.yml

  • Example: /root/omnia-backups

To execute the prepare_config.yml playbook, run the following command:

cd omnia/upgrade
ansible-playbook prepare_config.yml -i <Omnia_1.5.1_inventory_file_path>

Expected output of this playbook execution:

  • Auto-populated Omnia v1.6.1 configuration files in the <omnia_1.6.1_location>/omnia/input.

  • Auto-generated inventory file in Omnia v1.6.1 format. This is available in the <omnia_1.6.1_location>/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 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

Post prepare_config.yml execution, user must review or update the auto-populated configuration files in <omnia1.6.1_location>/omnia/input as mentioned below.

Note

To view/update the encrypted input files, user can use the ‘ansible-vault view’ or ‘ansible-vault edit’ command. For sample commands, click here.

  • Review the software_config.json which contains a list of all softwares identified for the cluster. This is used to configure the Omnia v1.6.1 local repository. For more information about local repository, click here.

    • Ensure there is a software entry(s) corresponding to the scheduler_type configured in Omnia v1.5.1 input configuration. For example, if scheduler_type is k8s,slurm in Omnia v1.5.1, then there must be a corresponding software entry(s) in the v1.6.1 software_config.json.

    • Similarly, if a security type (FreeIPA/OpenLDAP) is enabled in v1.5.1, then corresponding entry must be present in the software_config.json for Omnia v1.6.1.

    • If telemetry is enabled in Omnia v1.5.1, then the Omnia v1.6.1 software_config.json list should also contain the telemetry entry.

  • Add rhel_os_url in local repo_config.yml when the cluster OS type is RHEL.

  • Verify input/network_spec.yml for admin_network and bmc_network details.

  • If Omnia v1.5.1 installation had slurm set up, ensure that the v1.6.1 omnia_config.yml has slurm_installation_type updated as “configless”.

  • The new inventory format for Omnia v1.6.1 lists all Omnia v1.5.1 manager nodes as kube_control_plane and/or slurm_control_node based on the scheduler_type. All compute nodes will be listed as kube_node or slurm_node based on the scheduler_type.

  • Verify nfs_client_params details in input/storage_config.yml file, as mentioned below:

    • Omnia v1.6.1 upgrade configures the NFS server on the control plane, when enable_omnia_nfs is set to true in v1.5.1 omnia_config.yml. Verify that the server_ip corresponds to the IP address of the control plane.

    • Depending on the scheduler_type, that is, Slurm or Kubernetes, either k8s_share or slurm_share will be set to true for Omnia NFS share.

  • Ensure that the Omnia database backup has been created in the backup_location provided in upgrade_config.yml.

If you have any feedback about Omnia documentation, please reach out at omnia.readme@dell.com.