Recommended: Validating your production deployment

Instead of manually checking all the URLs and certificates that are created by your deployment, you can run a script to validate these objects automatically in a few minutes.

Before you begin

Make sure that your client machine can connect to the cluster you want to use, and has the necessary tools. Install the appropriate tools from the following list.

jq (a JSON processor open source tool)

On macOS:
1. How to install jq.
```
brew install jq
```
2. Verify the installation.
```
jq –version
jq --help
```
On CentOS/RHEL:
1. Install the EPEL Repository.
```
sudo yum install epel-release
```
2. Update the packages.
```
sudo yum update
```
3. Install jq.
```
sudo yum install jq
```
4. Verify the installation.
```
jq --version
jq --help
```

About this task

The post-installation script (bai-post-install.sh) is found in the cert-kubernetes-bai repository. The script helps you to assess the readiness of your bai deployment, and to retrieve and validate connection information to all its services. For more information about downloading cert-kubernetes-bai, see Preparing a client to connect to the cluster.

After you downloaded the CASE package and extracted the cert-kubernetes-bai archive, change directory to the /scripts folder under ibm-ba-insights/inventory/cp4aOperatorSdk/files/deploy/crs/cert-kubernetes-bai. The /scripts folder is the root folder ($ROOT_FOLDER) of the post-installation script.

The bai-post-install.sh script has four modes for a production deployment type:

precheck: The precheck mode gets some basic information about the cluster, the console, and the client.
status: The status mode gets the status of all the components from the custom resource (Ready | Not Ready | Not Installed).
console: The console mode gets the console connection information from the URLs and credentials.
probe: The probe mode checks the readiness and health of the deployment endpoints.

The script can be run with the following options:

./bai-post-install.sh --help
   --precheck         This mode gives information about the cluster and the client.
   --status           This mode gives the status of the services of the deployment. 
   --console          This mode gives the service URLs of the consoles in the deployment. 
   --probe            This mode checks the readiness of the deployment endpoints.

When you run the script in the status, console, or probe mode, the commands display information about the Business Automation Insights version and interim fix number of the installed deployment.

If no BAI production deployments are found on the cluster, then information about the cluster is displayed along with the following message:

No resources found for BAI Production deployment types.

If no BAI production deployments are found in the namespace in which you run the script, then information about the cluster is displayed along with the following message:

No BAI Production deployment found in namespace NAMESPACE.

Procedure

Make sure that you downloaded the cert-kubernetes-bai repository to a Linux® based machine (CentOS Stream/RHEL/MacOS) or a client to a Linux-based machine.
Make sure that you are in the $ROOT_FOLDER under cert-kubernetes-bai.
Log in to the target cluster as the <cluster-admin> user.
Using the Red Hat® OpenShift® CLI:
```
oc login https://<cluster-ip>:<port> -u <cluster-admin> -p <password>
```
On ROKS, if you are not already logged in:
```
oc login --token=<token> --server=https://<cluster-ip>:<port>
```
Check the values for the environment variables in the /helper/post-install/env.sh script under the $ROOT_FOLDER.
The variable that is the most important to check is for the foundational services namespace, as it can be customized and can be either cluster-scoped or namespace-scoped. The default value is set to ibm-common-services, which is for a cluster-scoped instance. If you installed foundational services in a namespace-scoped instance, you must change the value for your BAI deployment. The following example sets bai-project as the namespace-scoped instance.
```
BAI_COMMON_SERVICES_NAMESPACE=bai-project
```
Run the script in the "precheck" mode.
```
./bai-post-install.sh --precheck
```
Run the script in the "status" mode.
```
./bai-post-install.sh --status
```
The status of the listed components can be one of the following values:
- Ready is used to indicate that the component is installed successfully and ready to use.
- Not Ready is used to indicate that the component is not installed yet and is not ready to be used.
- Not Installed is used to indicate that the component is not included in the BAI deployment.
- Not found is used when the status value of the resource is missing. A Not found value usually indicates that the operator is changing the status.
Run the script in the "console" mode.
```
./bai-post-install.sh --console
```
The output provides valuable information about the available consoles, which can be shared and distributed to administrators and users who request access to the Business Automation Insights.
Run the script in the "probe" mode to know whether you can access and send requests to the deployment endpoints.
1. Add your values to the following parameters in the env.sh file, which is located under the $ROOT_FOLDER/helper/post-install folder.
  
  PROBE_USER_API_KEY
  
  A Platform API key that is generated for a specified user. For more information, see Generating API keys for authentication .
  
  PROBE_USER_NAME
  
  The name of the user in the API key. This user must have access rights to Business Automation Insights.
  
  PROBE_USER_PASSWORD
  
  The basic authentication password of the user.
  
  PROBE_VERBOSE
  
  Can be empty or enabled with '-v' to include extra debugging information. Extra log information can be useful to determine why an endpoint is not ready to receive traffic.
2. Then, run the following command:
```
./bai-post-install.sh --probe
```
  Note: Keep in mind that when you run the probe, OpenShift sends traffic to the pods only if the probe succeeds.
The probe mode returns one of the following messages for each endpoint:

OK

The probe succeeded. The endpoint is accessible by using a cURL command and the name of the application is returned.

BAD: <tested URL>

The probe failed. The endpoint is not accessible by using a cURL command. You can run the command from a command terminal to check that the endpoint is still inaccessible.

Unauthorized: <tested URL>

The probe failed due to user authorization. You can run the script again to check that the credentials are consistently rejected.

Not installed

Access to the endpoint failed. The cause of the failure can be Not Found, Forbidden, or Service Unavailable.

Cannot verify

The cURL command cannot be used to verify the endpoint. You must use a web browser to validate the endpoint.

What to do next

Some capabilities need you to follow post-deployment steps. For more information, see Completing post-installation tasks.

Attention: If you see connection errors to the external services, such as databases or an LDAP, after you installed your BAI deployment, then create an egress network policy to allow communication between your BAI deployment and the external services. The connection errors occur only when the external services are on the same cluster as your BAI deployment and in different namespaces. For more information, see Network policies to manage access to external services (egress) External link opens a new window or tab