Post-installation

Verify whether Business Teams Service (BTS) is properly deployed, and see how to scale it.

Verifying deployment

To verify BTS deployment

Verify that the BTS operator is created in the openshift-marketplace namespace. Run the following command
```
 oc get pods -n openshift-marketplace
```
Verify that the BTS pods are created in the namespace of deployment. Run the following command:
```
 oc get pods -n <namespace>
```
Navigate to http://<cpd_host>/teamserver/ui to access the UI where the cpd-host is the cpd route. To obtain the cpd route, run the following command:
```
 oc get route cpd
```
Log in with a user with a role that has the Administrate business teams permission. For more information, see Authorization.

Checking the deployment status

The BTS CR has a status section that that is updated by the operator:

oc get bts cp4ba-bts -o yaml

apiVersion: operator.ibm.com/v1alpha1
kind: BusinessTeamsService
metadata:
  name: bts
  namespace: ibm-common-services
spec:
  ...
status:
  deployStatus: ready
  serviceStatus: ready
  lastUpdated: "2021-10-21T17:17:57Z"
  reason: Service ibm-common-services/bts ready
  endpoints:
    adminUI: "https://cpd-host/teamserver/ui"
    teamsAPI: "https://cpd-host/teamserver/rest"
    apiExplorer: "https://cpd-host/teamserver/api/explorer"

The list of fields within the status section:

deployStatus indicates if all K8s resources are created, Possible values: ready or failed.
serviceStatus indicates service readiness. Possible values: unready (no pod ready) or ready (at least 1 pod ready).
reason is a human readable success or error message.
lastUpdated is the time of last status update.
endpoints contains the URLs of the service (BTS Admin UI, REST-API and REST-API-Explorer).

Scaling

BTS supports scaling using pre-defined deployment profiles and sizes. It is also possible to set replicas and resources manually.

Scaling using deployment profiles

To scale BTS using deployment profiles and sizes, complete the following actions:

Edit the BTS custom resource by running the following command:
```
 oc edit bts cp4ba-bts
```
Configure the spec.deploymentProfile and spec.deploymentProfileSize parameters to meet your requirements:

spec.deploymentProfile: Starter | Production spec.deploymentProfileSize: Small | Medium | Large

For Example:
```
 spec:
   deploymentProfile: Production
   deploymentProfileSize: Medium
```

The following are the pre-defined values for replicas and resources.

BTS pods:

Table 1. List pre-defined values for replicas and resources for BTS pods
Profile	Size	Replicas	Resource Requests	Resources Limits
Starter	n/a	1	cpu: 150m, mem: 256Mi	cpu: 500m, mem: 512Mi
Production	Small	2	cpu: 100m, mem: 256Mi	cpu: 400m, mem: 512Mi
Production	Medium	3	cpu: 100m, mem: 256Mi	cpu: 400m, mem: 512Mi
Production	Large	4	cpu: 100m, mem: 256Mi	cpu: 400m, mem: 512Mi

PostgreSQL pods:

Table 2. List of pre-defined values for replicas and resources for PostgreSQL pods
Profile	Size	Replicas	Resource Requests	Resource Limits
Starter	n/a	1	cpu: 50m, memory: 768Mi	cpu: 100m, memory: 1Gi
Production	Small	2	cpu: 50m, memory: 768Mi	cpu: 200m, memory: 1Gi
Production	Medium	2	cpu: 100m, memory: 768Mi	cpu: 300m, memory: 2Gi
Production	Large	2	cpu: 200m, memory: 768Mi	cpu: 400m, memory: 3Gi

Notes:

The Starter profile is not supported for production deployments.
The Starter profile does not distinguish between different sizes.
Resource Requests and Limits are per pod.
PostgreSQL deploys 1 primary active pod and several secondary inactive pods.

Scaling manually using replicas and resources

To scale BTS using replica counts and resources, complete the following steps:

Edit the BTS custom resource by running the following command:
```
 oc edit bts cp4ba-bts
```
Configure the replica counts using spec.replicas and spec.replicasDatabase:

For Example:
```
 spec:
   replicas: 3
   replicasDatabase: 2
```

Configure the pod resources counts using spec.resources and spec.resourcesPostgres:

For Example:

 spec:
   resources:
     requests:
       cpu: 400m
       memory: 256Mi
     limits:
       cpu: 1
       memory: 1Gi
   resourcesPostgres:
     requests:
       cpu: 100m
       memory: 512Mi
     limits:
       cpu: 400m
       memory: 1Gi