OIM Cleanup

The oim_cleanup.yml playbook can be utilized to roll back any configurations made on the OIM.

Tasks performed by the playbook

The oim_cleanup.yml playbook performs the following tasks:

• Clean up all containers, log files, and metadata on the OIM node.

• Clean up any PostgreSQL database deployed as part of BuildstreaM on the OIM.

• Rollback the firewall ports on the OIM node to its default setting.

Steps

1. To clean up the OIM and the PostgreSQL database which is deployed as part of BuildStreaM, perform one of the following:

   • If the BuildStreaM PostgreSQL database is not deployed on the OIM node, and you want to clean up the OIM, run the following command:

     ssh omnia_core
     cd /omnia/utils
     ansible-playbook utils/oim_cleanup.yml
     

   • If the BuildStreaM PostgreSQL database is deployed on the OIM node, and you want to clean up the OIM and the PostgreSQL database, run the following command:

     ssh omnia_core
     cd /omnia/utils
     ansible-playbook utils/oim_cleanup.yml -e postgres_backup=false
     

   Note

   • The postgres_backup parameter determines whether the PostgreSQL database should be backed up before cleanup.

   • If postgres_backup is set to true, the database will be backed up before cleanup.

   • If postgres_backup is set to false, the database will not be backed up before cleanup.

   • If the BuildStreaM PostgreSQL database is deployed on the OIM node, and you want to clean up the OIM but retain the PostgreSQL database, run the following command:

     ssh omnia_core
     cd /omnia/utils
     ansible-playbook utils/oim_cleanup.yml -e postgres_backup=true
     

   Important

   When prompted to back up the PostgreSQL database that you want to retain, record the database credentials. These credentials are required to restore the database when running the prepare_oim.yml playbook.

2. After running the oim_cleanup.yml playbook, do the following:

   1. Reboot the OIM node to ensure all changes take effect.

   2. The playbook does not remove data stored under the NFS server_share_path (See storage_config.yml).

      • Reusing the same server_share_path for new deployments can cause deployment failures or inconsistent Kubernetes/Slurm behavior.

      • For a fresh deployment, either manually clean this directory or use a new NFS export/path.

   3. The omnia_core container is not removed by oim_cleanup.yml.

      • To delete it, log in to the OIM node and run:

        omnia.sh --uninstall
        

Caution

• After a clean-up, when re-provisioning your cluster by re-running the discovery.yml playbook, ensure to use a different admin_nic_subnet in input/provision_config.yml to avoid a conflict with newly assigned servers. Alternatively, disable any OS available in the Boot Option Enable/Disable section of your BIOS settings (BIOS Settings > Boot Settings > UEFI Boot Settings) on all target nodes.

• On subsequent runs of discovery.yml, if users are unable to log into the server, refresh the ssh key manually and retry.

  ssh-keygen -R <node IP>
  

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