Configuring Automation assets

Administrative tasks in Automation assets include advanced configuration of the instance and configuring custom hostnames.

For information about everyday tasks in Automation assets, see Using Automation assets.

Providing user access

Automation assets provides fine-grained authorization by using Keycloak. For more information, see Cloud Pak roles and permissions.

Disabling runtime checks

To disable runtime checks, add the annotation com.ibm.cp4i/disable-webhook-runtime-checks: true to the Automation assets YAML:

metadata:
  annotations:
    com.ibm.cp4i/disable-webhook-runtime-checks: true

See Configuration for instructions on how to access the YAML.

Configuration

For advanced configuration options, log in to the Platform UI. Locate a deployed instance of Automation assets in the list. Click Edit, then click YAML.

Use the following table for reference.

Important: Review the information about the values that are set in the Replicas field.

Available options:

Field name	Description
Automation assets API image	The Docker registry location for pulling the Automation assets API image
Automation assets UI image	The Docker registry location for pulling the Automation assets UI image
Automation assets CouchDB image	The Docker registry location for pulling the Automation assets CouchDB image
Image pull policy	Configure whether you want images to be pulled every time, only if they're not present, or never
Image pull secrets	Configure the secret used for pulling images. If you're using the Entitled Registry and have created a secret for that, you should use that secret here.
Replicas	Number of replicas that each service has. The default is 3. Tip: Couch replicas are fixed during the first installation of your Automation assets. Changes to replicas after installation will only affect the UI and API services. See additional information below the table. Single replica-only mode restricts the number of replicas to one. This mode supports using a Block RWO volume for storing your asset data. Important: If using this mode, you can't increase the number of replicas after deployment. Also, upgrading an instance of Automation assets that was deployed in single replica-only mode causes Automation assets to become unavailable while the upgrade completes. Scalable mode allows you to deploy Automation assets by using one or more replicas. This mode requires you to use a File RWX volume for storing your asset data. Tip: With scalable mode, you can modify the number of replicas after deployment. Also, you can upgrade Automation assets without any downtime.
Annotations	Additional annotations to be added to Automation assets pods.
Node Selector	If you wish to assign the pods to a subset of the nodes of your cluster, you can use multiple Node Selectors. For more information, see Assigning Pods to Nodes in the Kubernetes documentation. Note: This setting only applies to Automation assets UI and API pods. CouchDB pods aren't affected.
Resources	Use the `Resources` section to override the default resource `request` and `limit` values. You can set limit and request values for the Automation assets API, UI, and CouchDB pods. Any values not configured here default to the values listed in "Default values:". For more information about request and limit values, see Requests and limits in the Kubernetes documentation. Important: For a given resource, if you set the request, you must also set the limit, and if you want to set the limit, you must also set the request. CouchDB search and management values are now deprecated and have no effect. To increase the resources available to the CouchDB container, use the "CouchDB db" resource values. Default values: The following values are the defaults for each resource. The request and limit values are the same for each resource. Important: You cannot create an Automation assets with values smaller than the following: Automation assets API CPU: `200m`. Automation assets API Memory: `150Mi`.Automation assets UI CPU: `200m`. Automation assets UI Memory: `150Mi`. CouchDB DB CPU: `300m`. CouchDB DB Memory: `700Mi`
Storage	Provide two different types of storage classes for use by the Automation assets: Asset data storage - Requires either a Block RWO volume (when deploying in single replica-only mode) or a File RWX volume (when deploying in scalable mode). For IBM Cloud Block, use the `ibmc-block-gold` storage class. For IBM Cloud File, use the `ibmc-file-gold-gid` storage class (specifically the `gid` variant). Asset metadata storage - Requires a Block RWO volume that meets POSIX requirements. For IBM Cloud Block, the `ibmc-block-gold` storage class must be used. For more information on storage classes in OpenShift, see storage classes for persistent storage or Cluster storage.*

* Volume access modes and availability:

Typically, RWO volumes (such as AWS Elastic Block Storage) are not replicated across availability zones (AZ), so Automation assets is pinned to a single AZ and is therefore not available if that AZ goes offline. Some RWO storage types, such as OpenShift Data Foundation Block Storage, do support replication across AZ, so they can be used to improve resilience. If your storage type doesn't support replication across AZ, create backups of your deployment so that you can recover the Automation assets instance if the AZ that contains the RWO volume goes offline permanently. For more information, see Backing up and restoring IBM Cloud Pak for Integration.
The best availability is typically provided by deploying with multiple replicas that are backed by ReadWriteMany (RWX) storage. This configuration ensures that if one of the replicas fails within an Availability Zone (AZ), the service is still available. Further resilience can be achieved using multiple AZs for running the service and replicated RWX storage, which ensures that the service continues if an AZ goes down. For more information on storage options and RWO support, see Storage considerations.

Configuring and reverting a custom hostname

Configuring a custom hostname

You must be an administrator to configure a custom hostname.

Add the following YAML to the AssetRepository custom resource. This can be done by using the Platform UI or by using the CLI. For uiHostname, enter a hostname.

spec:
  uiHostname: "example.app.acme.com"

After the spec.uiHostname value is applied, save the AssetRepository custom resource and wait until the Automation assets returns a status of Ready. You can now access Automation assets on the new hostname.

Reverting the custom hostname

Set the environment variables for your Automation assets instance:

export AUTOMATION_ASSETS_NAMESPACE=<namespace_where_automation_assets_instance_is_installed>
export AUTOMATION_ASSETS_NAME=<name_of_automation_assets_instance>

Delete spec.uiHostname from the AssetRepository custom resource.

oc patch assetrepository ${AUTOMATION_ASSETS_NAME} -n ${AUTOMATION_ASSETS_NAMESPACE} --type='json' --patch '[{ "op": "remove", "path": "/spec/uiHostname" }]'

The Automation assets instance status changes to Pending.

When the status of the Automation assets instance changes to Ready, the previous URL (before you configured a custom hostname) should be usable again.