Deploying OCP using nps autodeploy

Prerequisites
  • 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/ISO folder 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. For aruba, 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 KUBECONFIG
  • Ensure 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 autodeploy is in progress.

Procedure
  1. Log in to NPS toolkit VM.
  2. Initiate the NPS autodeployment using the following command:
    nps autodeploy --nos <nos_type>

    Supported nos_type are cumulus and aruba.

    The nps autodeploy starts with the ignition files creation.

The ignition files creation is in progress.

  1. While the nps autodeploy is 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 created
    
    NOTE:

    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.

  2. Open a new session of the NPS toolkit VM and run the following command:
    nps show --data vim
    NOTE:

    User can watch the output of the nps show --data vim command 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.

  3. To verify the newly created ignition files, navigate to /var/nps/ISO directory, and locate ign_config directory. The ign_config directory 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
  4. 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 autodeploy command 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.

  1. While the nps autodeploy is 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
    
  2. While bootstrap node installation is in progress, check the bootstrap node status using the following:
    1. Log in to the iLO console of the bootstrap node.
    2. 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 autodeploy automatically progresses further.

    3. 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:
      1. Open a new session for the NPS toolkit VM.

      2. SSH to bootstrap node using the following command:

        ssh core@<boostrap IP>
      3. Run the following command:

        journalctl -b -f -u bootkube.service
      4. Look for the string Waiting for etcd cluster in the log.

      5. If you find the string, press y in the prompt in the nps autodeploy session.

      6. If the string is not present, press n in the nps autodeploy session.

    4. After successful installation of the bootstrap node, the nps autodeploy command progresses further to install master nodes.

The master node installation is in progress.

  1. While the nps autodeploy is 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:
  2. While master node installation is in progress, check the master node status using the following:
    1. Log in to the iLO consoles of all the three master nodes.
    2. Verify that PXE boot is successfully completed.
    3. 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:
      1. Open a new session for the NPS toolkit VM.

      2. SSH to the bootstrap node using the following command:
        ssh core@<boostrap IP>
      3. Run the following command:
        journalctl -b -f -u bootkube.service
      4. Look for the string bootkube.service complete.

      5. If the string is not present, press n in 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 autodeploy command and proceed further.

      6. If you find the string, press y in the prompt in the nps autodeploy session.

    4. When the pause is provided for manually removing the bootstrap node, do the following verification procedure:
      1. Log in to the Bastion Host (NPS toolkit VM).

      2. Navigate to /var/nps/ISO/ign_config/.

      3. Run the following command:

        export KUBECONFIG=/var/nps/ISO/ign_config/auth/kubeconfig
      4. Ensure 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
      5. Check the status of master nodes before removing the bootstrap node using the following command:
        oc get nodes

        All masters nodes roles must be in Ready state.

        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 Ready state, see Worker or master nodes not in "READY" state for troubleshooting. Continue monitoring the status until all the master nodes are in Ready state.

        If the master nodes in oc get nodes get localhost as a hostname, see Master nodes get localhost as hostname.

  3. 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"
    
    1. 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.
    2. 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 check
      Example 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
      
    3. After modifying the DNS and Load balancer entries, proceed further for installation by entering Y.
      Following is the output of nps 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.

The worker node installation is in progress.

  1. 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):
  2. While worker node installation is in progress, do the following:
    1. Log in to the iLO Consoles of all the worker nodes.
    2. Verify that PXE boot is successfully completed.
  3. 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:
    1. Run the following command:
      export KUBECONFIG=/var/nps/ISO/ign_config/auth/kubeconfig
    2. Check for pending CSR using the following command:
      oc get csr
    3. 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 Ready state only after all pending CSRs are approved.

      • Takes 5-10 minutes for all the CSRs to be displayed.

    4. Check that the status of the worker nodes are in Ready state using the following command:
      oc get nodes
      NOTE:

      If the status is not in Ready state, see Worker or master nodes not in "READY" state for troubleshooting. Continue monitoring the status until all the worker nodes are in Ready state.

      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 nodes displays worker nodes with localhost as hostname, see Worker nodes get localhost as hostname.

    5. After the worker nodes are in Ready state, check for the cluster installation status Install 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 debug
      For 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 string Install complete is not present in the output mentioned above, do the following:
      1. Press n in the prompt on the nps autodeploy session.

      2. See Installation failure of master or worker nodes to resolve the issue.

      3. After applying the fix, run the nps autodeploy command from the NPS toolkit VM.

  4. After verifying the cluster status, check if all cluster operators AVAILABLE status is set to True again, using the following command:
    oc get co
    The 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
  5. If all cluster operators AVAILABLE status is True, press Y to continue the nps autodeploy.

Storage configuration is in progress

  1. Storage configuration is in progress and the following logs are displayed:
    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_STORAGE
    If the nps autodeploy fails and exits, see Storage configuration fails to fix the issue.

    After storage configuration is completed, the nps autodeploy command progresses to Image registry configuration.

Image registry configuration is in progress

  1. 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_REGISTRY

    After 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 autodeploy fails 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

  1. 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_OLM

    If the OLM configuration fails and autodeploy exits, see Configuring Operator Lifecycle Manager.

SR-IOV configuration is in progress

  1. 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_SRIOV

    The 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.

  2. Check the overall auto-deployment status after completion of the nps autodeploy command using the following command:
    nps show --data vim
    The 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 |
+------------+-------------------------------------+