If your on-premise installation fails, to get support from Cisco, collect the following details so we can help diagnose the root cause of your issue.
Obtain helm stderr output logs
Create a support bundle
Obtain helm stderr output logs
To obtain the helm stderr output on a failed deployment, you can view the deploy logs in the Admin Console Dashboard. To view the logs, click the following button:
From here, you will be shown a dialog with various logs. Choose the helmStderr logs as these often have valuable information as to why the deploy failed.
Create a support bundle
A support bundle contains details about the Provider Connectivity Assurance application that will help Cisco diagnose the reason for your deployment failure. Create a Support Bundle by following this guide.
Tips for self-diagnosing issues
To troubleshoot deployment issues on your own, generally you’ll need to access Kubernetes resources using the kubectl command. To be able to access the cluster via kubectl you must first use the Provider Connectivity Assurance CLI to setup your session using the shell command.
sudo ./provider-connectivity-assurance shellOnce this command is run, you now have access to running kubectl against your cluster.
The majority of the relevant resources reside in the pca namespace. Most troubleshooting efforts begin looking at pod statuses.
kubectl -n pca get podsPods in a erroneous state are often where focus should be given. Get more information about pods by viewing pod events using the describe command or looking at the pod logs.
For example, to view the pod description of the skylight-aaa pod:
kubectl -n pca describe pod -l app=skylight-aaaAnd to view its logs:
kubectl -n pca logs -l app=skylight-aaaTo workaround issues, often the solution is to edit a deployment, statefulset, configmap or other such Kubernetes resource. It is not recommended to do so without the aid of a Provider Connectivity Assurance support specialist. Another common troubleshooting tip is to delete pods so they are recreated with a fresh start.