Deploying OCP using
nps autodeploy
- Ensure that the proxy is not set in the environment variables. To disable the proxy, run the commands:
unset http_proxy unset https_proxy - Ensure that the servers are having physical drives as described in the BOM. There must not be any unassigned physical drives or USB.
- Ensure that all physical drives are clean.
If you have to clean up the drives, see HPE DL server cleanup procedure.
The cleanup is done to mitigate RHCOS limitation.
Perform the cleanup if you are reusing the physical drives.
- Ensure that all the required artifacts are available in
/var/nps/ISOfolder of NPS toolkit VM. For more information about the artifacts, see Download RHOCP and HPE Nimble CSI driver artifacts. Ensure that the switch automation is successful without any failures. If the network operating system type is
cumulus, see Deploying switch configuration. Foraruba, see Deploying switch configuration.Ensure that the HPE Nimble initialized and configured.
HPE Nimble is connected as described in the Port Map.
HPE Nimble has management port assigned.
HPE Nimble data port is configured with OCP range.
Ensure that the following environment variables are exported to run NPS commands:
export API_IP=<Customer_IP_assigned _to_NPS_VM> export NPSADMIN=<user name of admin mentioned in the nps_secret.yaml file> export NPSPASSWD=<password of admin user mentioned in the nps_secret.yaml file> export TOPOLOGY_NAME=<the deployment name mentioned in the TICG tool while creating the input.json file> export VIM_TYPE=<VIM platform type like RHOSP/RHOCP/VMWARE>Ensure to unset KUBECONFIG, if it is set in the environment variables, to run the Kubernetes commands. Use the following command to unset:
unset KUBECONFIGEnsure that the DNS is configured correctly for all the nodes described in the input JSON file.
Ensure that the Load Balancer entries contains all the nodes described in the input JSON file.
Ensure that all verification procedures, during
nps autodeploy, are performed in different sessions of NPS toolkit VM.Ensure that you do not exit or terminate the session where
nps autodeployis in progress.
- Log in to NPS toolkit VM.
-
Initiate the NPS autodeployment using the following command:
nps autodeploy --nos <nos_type>Supported
nos_typearecumulusandaruba.The
nps autodeploystarts with the ignition files creation.
The ignition files creation is in progress.
-
While the
nps autodeployis in progress, following is the output of ignition files creation:Prerequisite of having hw prep performed on all the servers met, proceeding for creating ignition file. Creating IGNITION FILES using {'action': 'create-ignition-files', 'force': False, 'api_ip': 'XX.XX.XX.XX', 'component': 'rhocp', 'logging': 'debug'} data Creating ignition files.. Ignition files are createdNOTE:The generated ignition files contains certificates that expire within 24 hours. Ensure that the RHOCP cluster (RHCOS worker nodes) installation is completed within 24 hours.
-
Open a new session of the NPS toolkit VM and run the following command:
nps show --data vimNOTE:User can watch the output of the
nps show --data vimcommand for the states while autodeploy is in progress throughout the process.The following is the result is displayed after successful creation of the ignition files:+-------------------+-----------------------------------------------+ | Key | Value | +-------------------+-----------------------------------------------+ | cluster_info | /nps/v2/computes/vim/rhocp/cluster_info/ | | compute_plane | /nps/v2/computes/vim/rhocp/compute_plane/ | | control_plane | /nps/v2/computes/vim/rhocp/control_plane/ | | persistent_volume | /nps/v2/computes/vim/rhocp/persistent_volume/ | | state | IGNITION_FILES_CREATED | | storage_backend | /nps/v2/computes/vim/rhocp/storage_backend/ | | subscription | /nps/v2/computes/vim/rhocp/subscription/ | +-------------------+-----------------------------------------------+
The VIM state is
IGNITION_FILES_CREATED. -
To verify the newly created ignition files, navigate to
/var/nps/ISOdirectory, and locateign_configdirectory. Theign_configdirectory contains the ignition files.These are the files and directories that gets created after completion of ignition file creation process.
-rw-r--r--. 1 root root 1815 Aug 4 14:31 master.ign -rw-r--r--. 1 root root 1815 Aug 4 14:31 worker.ign -rw-r--r--. 1 root root 295986 Aug 4 14:31 bootstrap.ign -rw-r--r--. 1 root root 94 Aug 4 14:31 metadata.json drwxr-xr-x. 2 root root 50 Aug 4 14:31 auth
-
In the NPS toolkit VM session opened for verification, take a backup of the ignition files using the following command:
#tar -cvzf config_files_backup.tar /var/nps/vim/Store the tar file in a secure location, ideally outside the NPS toolkit VM.
If
nps autodeploycommand execution is terminated and the creation of ignition files fail, see Failure during creation of ignition file to resume the autodeployment procedure.Using the ignition files, the bootstrap installation is performed by the
nps autodeploy.
The bootstrap installation is in progress.
-
While the
nps autodeployis in progress, following is the output of bootstrap installation:Bootstrap installation begins.. Baremetal install using {'api_ip': 'XX.XX.XX.XX', 'logging': 'debug', 'nos': 'aruba'} data PXE Booting using {'node': 'bootstrap', 'api_ip': 'XX.XX.XX.XX', 'logging': 'info', 'server_list': u'XX.XX.XX.XX'} data. Checking installation status for bootstrap node. Getting installation status by running ssh -o StrictHostKeyChecking=no core@XX.XX.XX.XX journalctl -b -f -u bootkube.service | grep 'Error: unhealthy cluster' command XX.XX.XX.XX IP not pingable, next retry after 3 minutes... Retrying the installation check : 1 XX.XX.XX.XX IP not pingable, next retry after 3 minutes... Retrying the installation check : 2 XX.XX.XX.XX IP not pingable, next retry after 3 minutes... Retrying the installation check : 3 XX.XX.XX.XX IP not pingable, next retry after 3 minutes... Retrying the installation check : 4 XX.XX.XX.XX IP not pingable, next retry after 3 minutes... Retrying the installation check : 5 XX.XX.XX.XX node IP is now pingable, checking for the installation status. Warning: Permanently added 'XX.XX.XX.XX' (ECDSA) to the list of known hosts. Killed by signal 15. Installation not completed, next retry after 3 minutes... Retrying the installation check : 6 XX.XX.XX.XX node IP is now pingable, checking for the installation status. Killed by signal 15. Found the required string in output data : Jul 20 13:31:17 Bootstrap.c10.qa.com bootkube.sh[5312]: Error: unhealthy cluster Installation completed for bootstrap node. Bootstrap installation ends..updating vim state as BOOTSTRAP_INSTALLED Bootstrap installation ends. Updated vim state: bootstrap_installed -
While bootstrap node installation is in progress, check the bootstrap node status using the following:
- Log in to the iLO console of the bootstrap node.
- Verify that the PXE boot is successfully completed.
If the bootstrap node is not PXE booted and the auto deployment is still in progress, see PXE boot issues with bootstrap or master or worker to rectify the issue.
If the resolution enables PXE booting the server successfully, the
nps autodeployautomatically progresses further.
- In case there a is timeout, look for the string
ERROR : Timeout waiting for bootstrap node installation completion, please check the status manually., and perform the following:Open a new session for the NPS toolkit VM.
SSH to bootstrap node using the following command:
ssh core@<boostrap IP>Run the following command:
journalctl -b -f -u bootkube.serviceLook for the string Waiting for etcd cluster in the log.
If you find the string, press y in the prompt in the
nps autodeploysession.If the string is not present, press n in the
nps autodeploysession.See Failure of bootstrap nodes installation to resolve the issue.
After applying the fix, run the
nps autodeploycommand from the NPS toolkit VM to proceed further.
- After successful installation of the bootstrap node, the
nps autodeploycommand progresses further to install master nodes.
The master node installation is in progress.
-
While the
nps autodeployis in progress, following is the output of master node installation:Master installation begins.. PXE Booting using {'node': 'master', 'api_ip': 'XX.XX.XX.XX', 'logging': 'info', 'server_list': u'XX.XX.XX.XX,XX.XX.XX.XX, XX.XX.XX.XX'} data. Checking installation status for master nodes. Getting installation status by running ssh -o StrictHostKeyChecking=no core@XX.XX.XX.XX journalctl -b -f -u bootkube.service | grep 'bootkube.service complete' command XX.XX.XX.XX node IP is now pingable, checking for the installation status. Found the required string in output data : Jul 20 16:56:47 Bootstrap.c10.qa.com bootkube.sh[5274]: bootkube.service complete Installation completed for master node. Remove bootstrap entry manually from Load Balancer and update the bootstrap DNS record to worker record in DNS and type yes to proceed: -
While master node installation is in progress, check the master node status using the following:
- Log in to the iLO consoles of all the three master nodes.
- Verify that PXE boot is successfully completed.
If the master node is not PXE booted, see PXE boot issues with bootstrap or master or worker to rectify the issue.
If the resolution enables PXE booting the server successfully, the
nps autodeploycommand automatically progresses further.
- In case there is a timeout, look for the string
ERROR : Timeout waiting for master cluster completion, please check the status manually., perform the following:Open a new session for the NPS toolkit VM.
- SSH to the bootstrap node using the following command:
ssh core@<boostrap IP> - Run the following command:
journalctl -b -f -u bootkube.service Look for the string
bootkube.service complete.If the string is not present, press
nin the prompt on the autodeploy screen.See Installation failure of master or worker nodes to resolve the issue.
After applying the fix, run the
nps autodeploycommand and proceed further.If you find the string, press
yin the prompt in thenps autodeploysession.
- When the pause is provided for manually removing the bootstrap node, do the following verification procedure:
Log in to the Bastion Host (NPS toolkit VM).
Navigate to
/var/nps/ISO/ign_config/.Run the following command:
export KUBECONFIG=/var/nps/ISO/ign_config/auth/kubeconfigEnsure that the bootstrap node is ready to be removed and check the logs using the following command:
openshift-install wait-for bootstrap-complete --log-level=info --dir=/var/nps/ISO/ign_config/The output of the command must show the bootstrap status as complete:DEBUG OpenShift Installer 4.3.29 DEBUG Built from commit 96253d3f2ed8da6f70ff6ad9f69d67b65c688889 INFO Waiting up to 30m0s for the Kubernetes API at https://api.c10.qa.com:6443... INFO API v1.16.2+283af84 up INFO Waiting up to 30m0s for bootstrapping to complete... DEBUG Bootstrap status: complete
- Check the status of master nodes before removing the bootstrap node using the following command:
oc get nodesAll masters nodes roles must be in
Readystate.For example:NAME STATUS ROLES AGE VERSION master-01.c10.qa.com Ready master 12h v1.16.2+45a4ac4 master-02.c10.qa.com Ready master 12h v1.16.2+45a4ac4 master-03.c10.qa.com Ready master 12h v1.16.2+45a4ac4
NOTE:If the status is not in
Readystate, see Worker or master nodes not in "READY" state for troubleshooting. Continue monitoring the status until all the master nodes are inReadystate.If the master nodes in
oc get nodesget localhost as a hostname, see Master nodes get localhost as hostname.
-
After the following CLI output is displayed and master nodes are successfully verified, do the following steps to proceed further with the installation:
" Installation completed for master node. Remove bootstrap entry manually from Load Balancer and update the bootstrap DNS record to worker record in DNS and type yes to proceed: y"
- Replace the bootstrap FQDN entry with the RHCOS worker node FQDN manually in the DNS server.
Example for before replacing of the bootstrap entry (forward)
master-01.ocp4 IN A XX.XX.XX.XX master-02.ocp4 IN A XX.XX.XX.XX master-03.ocp4 IN A XX.XX.XX.XX worker-01.ocp4 IN A XX.XX.XX.XX bootstrap.ocp4 IN A XX.XX.XX.XX
Example for after replacing of the bootstrap entry (forward)master-01.ocp4 IN A XX.XX.XX.XX master-02.ocp4 IN A XX.XX.XX.XX master-03.ocp4 IN A XX.XX.XX.XX worker-01.ocp4 IN A XX.XX.XX.XX worker-02.ocp4 IN A XX.XX.XX.XX
Example for before replacing of the bootstrap entry (reverse)40 IN PTR master-01.ocp4.qac.com. 41 IN PTR master-02.ocp4.qac.com. 42 IN PTR master-03.ocp4.qac.com. 43 IN PTR worker-01.ocp4.qac.com. 44 IN PTR bootstrap.ocp4.qac.com.
Example for after replacing of the bootstrap entry (reverse)40 IN PTR master-01.ocp4.qac.com. 41 IN PTR master-02.ocp4.qac.com. 42 IN PTR master-03.ocp4.qac.com. 43 IN PTR worker-01.ocp4.qac.com. 44 IN PTR worker-02.ocp4.qac.com.
- Remove the bootstrap entry and add a new worker node manually in both Load Balancers.
Example for before removing of bootstrap entry (external)
server bootstrap XX.XX.XX.XX:6443 check server master-01 XX.XX.XX.XX:6443 check server master-02 XX.XX.XX.XX:6443 check server master-03 XX.XX.XX.XX:6443 check
Example for after removing of bootstrap entry (external)server master-01 XX.XX.XX.XX:6443 check server master-02 XX.XX.XX.XX:6443 check server master-03 XX.XX.XX.XX:6443 check backend https-traffic-backend mode tcp option tcplog balance source server worker-01 XX.XX.XX.XX:443 check server worker-02 XX.XX.XX.XX:443 check backend http-traffic-backend mode tcp option tcplog balance source server worker-01 XX.XX.XX.XX:80 check server worker-02 XX.XX.XX.XX:80 checkExample for before removing of bootstrap entry (internal)server bootstrap XX.XX.XX.XX:22623 check server master-01 XX.XX.XX.XX:22623 check server master-02 XX.XX.XX.XX:22623 check server master-03 XX.XX.XX.XX:22623 check
Example for after removing of bootstrap entry (internal)server master-01 XX.XX.XX.XX:22623 check server master-02 XX.XX.XX.XX:22623 check server master-03 XX.XX.XX.XX:22623 check backend https-traffic-backend mode tcp option tcplog balance source server worker-01 XX.XX.XX.XX:443 check server worker-02 XX.XX.XX.XX:443 check backend http-traffic-backend mode tcp option tcplog balance source server worker-01 XX.XX.XX.XX:80 check server worker-02 XX.XX.XX.XX:80 check - After modifying the DNS and Load balancer entries, proceed further for installation by entering
Y.Following is the output ofnps autodeploy:updating the individual server vim state of XX.XX.XX.XX IP with {'state': {u'pxe_vlanid': u'3401', 'vim': 'REGISTERED', u'baremetal': {u'install': u'in progress'}, u'hw_prep': {u'bios_settings': u'completed', u'raid': u'completed', u'nic_boot_order': u'completed', u'snmp': u'completed', u'profile_validation': u'success', u'create_user': u'completed', u'nic_settings': u'completed', u'ilo_naming': u'completed'}, u'dhcp': u'success', u'odim': u'completed'}} data updating the individual server vim state of XX.XX.XX.XX IP with {'state': {u'pxe_vlanid': u'3401', 'vim': 'REGISTERED', u'baremetal': {u'install': u'in progress'}, u'hw_prep': {u'bios_settings': u'completed', u'raid': u'completed', u'nic_boot_order': u'completed', u'snmp': u'completed', u'profile_validation': u'success', u'create_user': u'completed', u'nic_settings': u'completed', u'ilo_naming': u'completed'}, u'dhcp': u'success', u'odim': u'completed'}} data updating the individual server vim state of XX.XX.XX.XX IP with {'state': {u'pxe_vlanid': u'3401', 'vim': 'REGISTERED', u'baremetal': {u'install': u'in progress'}, u'hw_prep': {u'bios_settings': u'completed', u'raid': u'completed', u'nic_boot_order': u'completed', u'snmp': u'completed', u'profile_validation': u'success', u'create_user': u'completed', u'nic_settings': u'completed', u'ilo_naming': u'completed'}, u'dhcp': u'success', u'odim': u'completed'}} data Master installation ends.. updating vim state as MASTER_CLUSTER_CONFIGURED Master installation ends. Updated vim state: master_cluster_configured
The next step in nps autodeploy is worker node installation.
- Replace the bootstrap FQDN entry with the RHCOS worker node FQDN manually in the DNS server.
The worker node installation is in progress.
-
While the nps autodeploy is in progress, following is the output of the worker node installation:
RHCOS Worker Installation begins.. Deleting baremetal pod Token created successfully!! Border Leaf Switch UUID : [u'fe020dc1-703c-4590-90c4-a1d1f2b62fea', u'bf0be7b5-674d-4f77-a140-fc96f49b41b'] Fabric UUID is c046701d-4b36-42bb-8a40-8d704bdff9c2 Data for put_dhcp_relay : {'dhcp_relay': [{'switch_uuids': [u'fe020dc1-703c-4590-90c4-a1d1f2b62fea', u'bf0be7b5-674d-4f77-a140-fc96f49b641b'], 'vlans': u'3401', 'ipv4_dhcp_server_addresses': []}]} DHCP Configured Successfull !! Changing role from bootstrap to worker Bringing up baremetal pod Baremetal install using {'api_ip': 'XX.XX.XX.XX', 'logging': 'debug', 'nos': 'aruba'} data Powering on worker nodes.. PXE Booting [u'XX.XX.XX.XX', u'XX.XX.XX.XX'] servers PXE Booting using {'api_ip': 'XX.XX.XX.XX', 'logging': 'info', 'server_list': u'XX.XX.XX.XX,XX.XX.XX.XX'} data. Installing RHCOS worker nodes.... Approve all the pending CSR certificates for both the worker nodes. Once all are approved, both rhcos worker nodes should be in ready state Navigate to /var/nps/ISO/ign_config directory of NPS Toolkit VM and run the below command openshift-install wait-for install-complete --dir=/var/nps/ISO/ign_config/ --log-level debug Wait till you find the string 'Install complete!' if you find the string press Yes or No in below condition check whether the worker nodes are in a ready state, if yes press Y else press N (Y/N): -
While worker node installation is in progress, do the following:
- Log in to the iLO Consoles of all the worker nodes.
- Verify that PXE boot is successfully completed.
If the worker nodes are not PXE booted, see PXE boot issues with bootstrap or master or worker to rectify the issue.
If the resolution enables PXE booting the server successfully, the
nps autodeploycommand progresses further.
-
After the pause is provided for verifying the worker nodes and cluster status, log in to the Bastion Node (NPS tookit VM) and perform the following steps:
- Run the following command:
export KUBECONFIG=/var/nps/ISO/ign_config/auth/kubeconfig - Check for pending CSR using the following command:
oc get csr - Approve all pending CSR using the following command:
oc adm certificate approve <CSR Name>Keep checking for all the pending CSR.
Approve them one by one until all the CSRs are approved.
Worker nodes will move to
Readystate only after all pending CSRs are approved.Takes 5-10 minutes for all the CSRs to be displayed.
- Check that the status of the worker nodes are in
Readystate using the following command:oc get nodesNOTE:If the status is not in
Readystate, see Worker or master nodes not in "READY" state for troubleshooting. Continue monitoring the status until all the worker nodes are inReadystate.For example:NAME STATUS ROLES AGE VERSION master-01.c10.qa.com Ready master 12h v1.16.2+45a4ac4 master-02.c10.qa.com Ready master 12h v1.16.2+45a4ac4 master-03.c10.qa.com Ready master 12h v1.16.2+45a4ac4 worker-01.c10.qa.com Ready worker 12h v1.16.2+45a4ac4 worker-02.c10.qa.com Ready worker 12h v1.16.2+45a4ac4
NOTE:If the
oc get nodesdisplays worker nodes with localhost as hostname, see Worker nodes get localhost as hostname. - After the worker nodes are in
Readystate, check for the cluster installation statusInstall complete, and capture the credentials for accessing the cluster using the following command:openshift-install wait-for install-complete --dir=/var/nps/ISO/ign_config --log-level debugFor example, the log displays the following:[root@npsvm rhocp]# openshift-install wait-for install-complete --dir=/var/nps/ISO/ign_config --log-level debug DEBUG OpenShift Installer 4.3.29 DEBUG Built from commit 96253d3f2ed8da6f70ff6ad9f69d67b65c688889 DEBUG Fetching Install Config... DEBUG Loading Install Config... DEBUG Loading SSH Key... DEBUG Loading Base Domain... DEBUG Loading Platform... DEBUG Loading Cluster Name... DEBUG Loading Base Domain... DEBUG Loading Platform... DEBUG Loading Pull Secret... DEBUG Loading Platform... DEBUG Using Install Config loaded from state file DEBUG Reusing previously-fetched Install Config INFO Waiting up to 30m0s for the cluster at https://api.c10.qa.com:6443 to initialize... DEBUG Cluster is initialized INFO Waiting up to 10m0s for the openshift-console route to be created... DEBUG Route found in openshift-console namespace: console DEBUG Route found in openshift-console namespace: downloads DEBUG OpenShift console route is created INFO Install complete! INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/var/nps/ISO/ign_config/auth/kubeconfig' INFO Access the OpenShift web-console here: https://console-openshift-console.apps.c10.qa.com INFO Login to the console with user: kubeadmin, password: XXXXXXXX-XXXX-XXXXX
If the stringInstall completeis not present in the output mentioned above, do the following:Press n in the prompt on the
nps autodeploysession.See Installation failure of master or worker nodes to resolve the issue.
After applying the fix, run the
nps autodeploycommand from the NPS toolkit VM.
- Run the following command:
-
After verifying the cluster status, check if all cluster operators
AVAILABLEstatus is set toTrueagain, using the following command:oc get coThe following output is displayed:[root@npsvm auth]# oc get co NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE authentication 4.3.29 True False False <invalid> cloud-credential 4.3.29 True False False 62m cluster-autoscaler 4.3.29 True False False 46m console 4.3.29 True False False 4m20s dns 4.3.29 True False False 51m image-registry 4.3.29 True False False 48m ingress 4.3.29 True False False 5m36s insights 4.3.29 True False False 49m kube-apiserver 4.3.29 True False False 51m kube-controller-manager 4.3.29 True False False 49m kube-scheduler 4.3.29 True False False 49m machine-api 4.3.29 True False False 51m machine-config 4.3.29 True False False 51m marketplace 4.3.29 True False False 48m monitoring 4.3.29 True False False 2m47s network 4.3.29 True False False 56m node-tuning 4.3.29 True False False 43m openshift-apiserver 4.3.29 True False False 49m openshift-controller-manager 4.3.29 True False False 52m openshift-samples 4.3.29 True False False 46m operator-lifecycle-manager 4.3.29 True False False 49m operator-lifecycle-manager-catalog 4.3.29 True False False 50m operator-lifecycle-manager-packageserver 4.3.29 True False False 49m service-ca 4.3.29 True False False 54m service-catalog-apiserver 4.3.29 True False False 50m service-catalog-controller-manager 4.3.29 True False False 49m storage 4.3.29 True False False 48m
-
If all cluster operators
AVAILABLEstatus isTrue, pressYto continue thenps autodeploy.
Storage configuration is in progress
-
Storage configuration is in progress and the following logs are displayed:
If the
RHCOS WORKER INSTALL ends..patching VIM state as RHCOS_WORKER_ADDED RHCOS WORKER INSTALL ends. Updated VIM state: rhcos_worker_added In configure_storage_and_configure_image_registry with vim state rhcos_worker_added Running configure-storage CLI Performing configure-storage using {'action': 'configure-storage', 'component': 'rhocp', 'api_ip': 'XX.XX.XX.XX', 'force': False, 'logging': 'debug'} data VIM State after configure storage : CONFIGURING_STORAGE VIM State after configure storage : CONFIGURING_STORAGEnps autodeployfails and exits, see Storage configuration fails to fix the issue.After storage configuration is completed, the
nps autodeploycommand progresses to Image registry configuration.
Image registry configuration is in progress
-
Image registry configuration is in progress and the following logs are displayed:
Running configure-image-registry CLI Performing configure-image-registry using {'action': 'configure-image-registry', 'component': 'rhocp', 'api_ip': 'XX.XX.XX.XX', 'force': False, 'logging': 'debug'} data VIM State after configure image registry : CONFIGURING_IMAGE_REGISTRY VIM State after configure image registry : CONFIGURING_IMAGE_REGISTRYAfter the image registry configuration is completed, the following is the output of the autodeploy:
Completed configure-storage and configure-image-registry operation, updated vim state is image_registry_configured In configure_olm_and_sriov with vim state image_registry_configured
If the
nps autodeployfails and exits, see Image registry configuration failed to fix the issue.After the storage and image registry are configured using
nps autodeploy, it proceeds further.
OLM is in progress
-
Autodeploy proceeds to configure OLM and operator hub in case of disconnected install.
NOTE:
OLM is not applicable for online mode of RHOCP installation.
In configure_olm_and_sriov with vim state image_registry_configured Running OLM configuration CLI Performing configure-olm using {'action': 'configure-olm', 'component': 'rhocp', 'api_ip': 'XX.XX.XX. XX', 'force': False, 'logging': 'debug'} data VIM State after OLM configure : CONFIGURING_OLMIf the OLM configuration fails and autodeploy exits, see Configuring Operator Lifecycle Manager.
SR-IOV configuration is in progress
-
Autodeploy proceeds to configuring SR-IOV on worker nodes.
Running SRIOV configuration CLI Performing configure-sriov using {'action': 'configure-sriov', 'component': 'rhocp', 'api_ip': 'XX.XX .XX.XX', 'force': False, 'logging': 'debug'} data VIM State after SRIOV configure : CONFIGURING_SRIOVThe following is the output of autodeploy CLI after OLM and SR-IOV configuration:
Completed configure-olm and configure-sriov, updated vim state is sriov_configured
If the SR-IOV configuration fails, see Configuring SR-IOV.
-
Check the overall auto-deployment status after completion of the
nps autodeploycommand using the following command:nps show --data vimThe following output is displayed:[root@npsvm auth]# nps show --data vim +-------------------+-----------------------------------------------+ | Key | Value | +-------------------+-----------------------------------------------+ | cluster_info | /nps/v2/computes/vim/rhocp/cluster_info/ | | compute_plane | /nps/v2/computes/vim/rhocp/compute_plane/ | | control_plane | /nps/v2/computes/vim/rhocp/control_plane/ | | local_registry | /nps/v2/computes/vim/rhocp/local_registry/ | | persistent_volume | /nps/v2/computes/vim/rhocp/persistent_volume/ | | redhat_registry | /nps/v2/computes/vim/rhocp/redhat_registry/ | | sriov | /nps/v2/computes/vim/rhocp/sriov/ | | state | OCP_CLUSTER_CONFIGURED | | storage_backend | /nps/v2/computes/vim/rhocp/storage_backend/ | +-------------------+-----------------------------------------------+
Installation is completed.
Installation completed successfully !! +------------+-------------------------------------+ | Process | Status | +------------+-------------------------------------+ | AUTODEPLOY | OCP CLUSTER CONFIGURED SUCCESSFULLY | +------------+-------------------------------------+