When twistcli installs Console into a Kubernetes or OpenShift cluster, it executes a series of steps.
To help you troubleshoot issues when twistcli fails, the steps in the install flow are described here:
Loads the Console image on localhost, and tags it with the registry address.
Deletes the old Console replication controller, if it exists, and waits for Console deletion.
Deletes the config map, if it exists.
Creates Prisma Cloud namespace, if it does not exist.
If the service does not exist, twistcli resolves the service template to a file and creates a new service.
If persistent volume claim (PVC) does not exist, twistcli resolves the PVC template to a file and creates a new PVC.
Waits to the PVC to bind to a persistent volume resource.
twistcli expects that the persistent volume has already been created by the user.
Note that the PVC is not deleted and recreated because once the PVC is be deleted, it cannot bind again to the persistent volume without recreating the persistent volume.
Retrieves the service IPs (Cluster IPs, and adds them to the SAN.
Creates a config map.
Resolves Console template to a file, and creates a Console replication controller.