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
timescaledbpod is inrunningstate.
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 |
|---|---|
|
|
|
|
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/upgradefolder and will be used later during the execution of upgrade.yml.Backup of the Omnia v1.5.1 database is created at the
backup_locationspecified in theupgrade_config.yml. The backup file is named asbackup.sql.Backup of the Omnia v1.5.1 telemetry database is created at the
backup_locationspecified in theupgrade_config.yml. The backup file is named astelemetry_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.jsonwhich 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_typeconfigured in Omnia v1.5.1 input configuration. For example, ifscheduler_typeisk8s,slurmin Omnia v1.5.1, then there must be a corresponding software entry(s) in the v1.6.1software_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.jsonfor Omnia v1.6.1.If telemetry is enabled in Omnia v1.5.1, then the Omnia v1.6.1
software_config.jsonlist should also contain thetelemetryentry.
Add
rhel_os_urlinlocal repo_config.ymlwhen the cluster OS type is RHEL.Verify
input/network_spec.ymlforadmin_networkandbmc_networkdetails.If Omnia v1.5.1 installation had slurm set up, ensure that the v1.6.1
omnia_config.ymlhasslurm_installation_typeupdated as “configless”.The new inventory format for Omnia v1.6.1 lists all Omnia v1.5.1 manager nodes as
kube_control_planeand/orslurm_control_nodebased on thescheduler_type. All compute nodes will be listed askube_nodeorslurm_nodebased on thescheduler_type.Verify
nfs_client_paramsdetails ininput/storage_config.ymlfile, as mentioned below:Omnia v1.6.1 upgrade configures the NFS server on the control plane, when
enable_omnia_nfsis set to true in v1.5.1omnia_config.yml. Verify that theserver_ipcorresponds to the IP address of the control plane.Depending on the
scheduler_type, that is, Slurm or Kubernetes, eitherk8s_shareorslurm_sharewill be set totruefor Omnia NFS share.
Ensure that the Omnia database backup has been created in the
backup_locationprovided inupgrade_config.yml.
If you have any feedback about Omnia documentation, please reach out at omnia.readme@dell.com.