Aura –

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Dependencies update in Prince 10.0.0 release

These documents include all the updates in components that have been carried out for the release Prince 10.0.0, along with the corresponding migration or adaptation tasks that should be executed by the OBs Teams.

Index

Python repositories migration for PyUtils, Aura NLP, Aura Complex Logic Framework plugin packages and ATRIA repositories.
Nodejs-related dependencies update in Prince release

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Update CLU API version for releases previous to Nodoubt 9.11.0

In releases previous to Nodoubt 9.11.0, it is required to update the CLU API used for the clu-storage

Introduction

The current version of the CLU API used for the clu-storage (2023-04-15-preview) will be deprecated on March 31, 2025.

This version should be updated to 2024-11-15-preview for all environments before this date by the GES Team.

The update of the CLU API version enables the copy of CLU projects in cache. This leads to more efficient processes: reuse of CLU trainings with no need for retraining, reduced deployment times, hot swapping processes, etc.

On the other hand, this update does not impact in the use of Aura NLP.

Steps to update CLU API version

To update the version of the CLU API, follow the steps below:

Prerequisite: A kubeconfig of the environment must be previously configured.

Access to edit configuration:

  kubectl edit configmap nlp-provisioning-bootstrap -n <namespace>

In the section clu of the nlp-provisioning-bootstrap configmap, the value storage_api_version should be updated to 2024-11-15-preview.
Save and close the ConfigMap.

Restart nlp-provisioning deployment:

  kubectl rollout restart deployment/nlp-provisioning -n <namespace>

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Configuration for Nodoubt 9.11.0 release

Requisites for the proper operation of Nodoubt 9.11.0 release

aura-databricks-jobs configuration

Manual removal of files from Microsoft Storage account

A pre-requisite in Nodoubt release is required for the component aura-databricks-jobs:

The Operations Teams must eliminate manually the files configured in the common storage of the Microsoft Storage account defined in the aura-databricks-jobs environment variable AURA_MICROSOFT_AZURE_STORAGE_COMMON_ACCOUNT. These files are not needed anymore, but remain when a new release is installed.

The files need to be deleted from two locations:

/sizeReportDefault.json
avro/sizeReportDefault.json

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Workaround for Metallica 9.9.0 release

Description of the workaround required for Metallica release, that implies the restart of ATRIA components

Required ATRIA components restart

In Metallica release, for environments that can be suspended and set up again (DEV and PRE environments), it is required to restart two ATRIA components: atria-model-gateway and atria-rag-server.

For this purpose, follow these guidelines:

First, get sure that aura-configuration-api is up and running
Now, restart ATRIA components:
atria-model-gateway
kubectl rollout restart deployment atria-model-gw -n <namespace>
atria-rag-server
kubectl rollout restart deployment atria-rag -n <namespace>

In both cases, substitute <namespace> with the corresponding environment.

This requirement does not apply to PRO environments.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Update Kiss 9.7.0 release configuration

Guidelines to update Kiss base configuration:

Update aura-avro-adapter.json configuration for aura-kpis-uploader in the Azure common storage.

Prerequisites

A kubeconfig of the Aura environment must be configured.
Substitute <YOUR_ENV> with the corresponding environment: es-pre, es-pro, br-pre, de-pre, de-int, etc.
The installation output file (output_install/<YOUR_ENV>_info.json) to get:
- The KPI blob container name:
  - Get <AURA_KPI_CONTAINER> value.
- The KPI blob container name:
  - Substitute <AURA_KPI_CONTAINER> with the obtained value.
- The connection of azure common account
  - Substitute <AURA_MICROSOFT_AZURE_STORAGE_COMMON_ACCOUNT> with the obtained value.
  - Substitute <AURA_MICROSOFT_AZURE_STORAGE_COMMON_ACCESS_KEY> with the obtained value.

PATH_TO_YOUR_OUTPUT_INSTALL_ENV_FILE=output_install/<YOUR_ENV>_info.json
AURA_KPI_CONTAINER=$(cat ${PATH_TO_YOUR_OUTPUT_INSTALL_ENV_FILE}|jq -r .kpi_blob_container_name)
AURA_MICROSOFT_AZURE_STORAGE_COMMON_ACCOUNT=$(cat ${PATH_TO_YOUR_OUTPUT_INSTALL_ENV_FILE}|jq -r .common_azure_storage_account_name)
AURA_MICROSOFT_AZURE_STORAGE_COMMON_ACCESS_KEY=$(cat ${PATH_TO_YOUR_OUTPUT_INSTALL_ENV_FILE}|jq -r .common_azure_storage_access_key)

Update aura-kpis-uploader configuration

Update aura-avro-adapter configuration file

Connect to Azure common account with the credentials of the Azure common account and KPI blob container.
Remove the file schemas/aura-avro-adapter.json.
When aura-kpis-uploader is run, a new json file will be generated, with the updated configuration.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Update Imagine Dragons 9.5.0 base configuration

Guidelines to update Imagine Dragons base configuration:

Update scopes configuration for aura-bot and aura-billing Kernel clients, and use them in Databricks executions
Update aura-gateway-api environment variables to control how KPI entities are written

Prerequisites

In the corresponding Kernel deployment, all Aura datasets are published and the corresponding scopes are configured to aura-bot and aura-billing clients.
A kubeconfig of the Aura environment must be configured.
Substitute <YOUR_ENV> with the corresponding environment: es-pre, es-pro, br-pre, de-pre, de-int, etc.
The installation output file (output_install/<YOUR_ENV>_info.json) to get:
- The KPI blob container name:
  - Substitute <AURA_KPI_CONTAINER> with the obtained value.

PATH_TO_YOUR_OUTPUT_INSTALL_ENV_FILE=output_install/<YOUR_ENV>_info.json
AURA_KPI_CONTAINER=$(cat ${PATH_TO_YOUR_OUTPUT_INSTALL_ENV_FILE}|jq -r .kpi_blob_container_name)

Update aura-databricks-jobs configuration

Update aura-bot scopes

Add these scopes in the Kernel app of aura-bot:

admin:datasets:read
data:read
data:write

Update aura-billing scopes

Add these scopes in the Kernel app of aura-bot.

admin:datasets:read
data:read
data:write

Update Databricks deployment

It will be necessary to deploy Aura core, indicated in core deployment. This will update the configuration with the following changes:

Update the profile to be multi-node instead of single node, configuring workers autoscaled.
Update the Databricks cluster node type, modifying databricks.cluster.node_type_id configuration:
```
databricks:
  cluster:
    node_type_id: "Standard_DS4_v2"
```

Add autoscale config in cluster:

databricks:
 cluster:  
   config:
      autoscale:
         enabled: true
         min_workers: 2
         max_workers: 4

Update cluster’s config, including a new config element to add spark config as dynamic allocation enabled or executor memory and cores:

databricks:
  cluster:  
    config:
      "spark.debug.maxToStringFields": "100"
      "spark.driver.memory": "4g"
      "spark.executor.memory": "4g"
      "spark.dynamicAllocation.enabled": "true"
      "spark.executor.cores": "4"

Update aura-gateway-api environment variables to control KPI entities writing

Follow these guidelines to update aura-gateway-api environment variables to control the way KPIs entities are written.

This step can be executed at any time, because it is a performance improvement and will be the default configuration in the following release. But it should be applied as a workaround if the aura-gateway-api starts failing and returns responses with 503 or 502 statuses, meaning that the KPI writing processes are consuming all the server resources.

Connect to the environment using your kubeconfig.
Read the name of the container where the KPI entities files are being written.
Edit the config-map of aura-gateway-api to update the variables.
```
kubectl -n <YOUR_ENV> edit cm aura-gateway-api -o 
...
```
Substitute or add the following environment variables.

If an environment variable is not in the config map, it means that the used value is the default one. Please refer to the aura-gateway-api environment variables documentation for further information.

AURA_KPIS_BLOB_STORE_INTERVAL: 3600000
AURA_KPIS_BLOB_STORE_MAX_BLOCK_BYTES: 2500000
AURA_KPIS_LOG_API_REQUEST_BODY: 'false'
AURA_KPIS_LOG_API_RESPONSE_BODY: 'false'
AURA_HTTP_PATHS_LOG_DISABLED: `v1/.well-known, aura-configuration, metrics, healthz, <AURA_KPI_CONTAINER>'

Restart aura-gateway-api pods:

kubectl -n <YOUR_ENV> rollout restart aura-gateway-api

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Update Germany configuration for Imagine Dragons 9.5.0

Guidelines to update Germany default configuration for Imagine Dragons:

To apply the correct brand in all the channels and applications
To point to the correct Kernel deployment
To avoid issues of Databricks deployment compatibility with Confidential Computing

Prerequisites

In the corresponding Kernel deployment, all Aura datasets are published and the corresponding scopes are configured to aura-bot client.
There is an AURA_CONVERSATIONS container in Kernel Azure Storage.
A kubeconfig of the Aura environment must be configured.
Substitute <YOUR_ENV> with the corresponding pre-production environment: es-pre, es-cert, br-pre, de-pre, de-int, etc.
The installation output file (output_install/<YOUR_ENV>_info.json) to get:
- The APIKey of Aura to access aura-configuration-api.
  - Substitute <AURA_API_KEY> with the obtained value.

PATH_TO_YOUR_OUTPUT_INSTALL_ENV_FILE=output_install/<YOUR_ENV>_info.json
AURA_API_KEY=$(cat ${PATH_TO_YOUR_OUTPUT_INSTALL_ENV_FILE}|jq -r .aura_bot_services_api_key)

Include new brand as a valid one

Connect to the environment using your kubeconfig.
Edit the config-map of aura-configuration-api to include the new brand.
- To include WhatsAppSim in Germany as new brand, just substitute <NEW_BRAND_ID> with 0111.
Access the full list of Brands defined in Kernel

kubectl -n <YOUR_ENV> edit cm aura-configuration-api -o 
apiVersion: v1
data:
  AURA_BRANDS: 0101,10000,<NEW_BRAND_ID>
...

Restart aura-configuration-api pods:

kubectl -n <YOUR_ENV> rollout restart aura-configuration-api

Change already existing channels and applications brands to point to the new one

Change channels

Substitute <UUID> with a valid UUID version 4 generated for every request.
Substitute <AURA_API_KEY> with the Aura API key read from the environment installation file.
Substitute <CHANNEL_ID> with the channel to be configured.
Substitute <NEW_BRAND_ID> with the brand to be configured.

curl --location --request PATCH 'https://<YOUR_ENV>.auracongnitve.com/aura-services/v2/configuration/channels/<CHANNEL_ID>'
\
--header 'correlator: <UUID>' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: APIKEY <AURA_API_KEY>' \
--data '{
    "id": "<CHANNEL_ID>",    
    "brand": "<NEW_BRAND_ID>"
}'

Changes in Germany, the previous PATCH should be executed twice, at least, once per existing channel:
- Sprinklr web chat channel identifier: 33a4dcdc-0ef7-4bf1-886f-48d4fda2a031
- Testing channel identifier: afec79db-dc0d-4c2e-a098-6c996503a7b4

Change applications

Substitute <UUID> with a valid UUID version 4 generated for every request.
Substitute <AURA_API_KEY> with the Aura APIKey read from the environment installation file.
Substitute <APPLICATION_ID> with the application to be configured.
Substitute <NEW_BRAND_ID> with the brand to be configured.

curl --location --request PATCH 'https://<YOUR_ENV>.auracongnitve.com/aura-services/v2/configuration/applications/<APPLICATION_ID>'
\
--header 'correlator: <UUID>' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: APIKEY <AURA_API_KEY>' \
--data '{
    "id": "<APPLICATION_ID>",    
    "brand": "<NEW_BRAND_ID>"
}'

Changes in Germany, the previous PATCH should be executed once, at least, to update ATRIA application:
- ATRIA application: 7586c369-b6a0-4fa5-9416-d8b45920274c

Change Kernel configuration in Aura components

Review the following variables in your environment profile:

fourth_platform:
  client_id: "aura-bot" # Aura 4P app client id
  client_secret: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          <THE_SECRET_FOR_AURA_BOT_IN_KERNEL>
  apigw_url: "https://api.<KERNEL_DEPLOYMENT>.baikalplatform.com" # must be filled with the right value. Usually https://api.{{environment_profile}}-{{environment_type}}.baikalplatform.com

For example, in Germany, for WhatsappSim Kernel, the URL should be:
- de-int: https://api.de-int-whatsappsim.baikalplatform.com
- de-pre: https://api.de-pre-whatsappsim.baikalplatform.com
- de-pro: https://api.de-pro-whatsappsim.baikalplatform.com
For aura-kpis-uploader, assure that AURA_MICROSOFT_AZURE_STORAGE_CONTAINER_DESTINATION and AURA_MICROSOFT_AZURE_STORAGE_ACCESS_KEY_DESTINATION belong to the corresponding Kernel deployment.
Execute deploy_core to assure that the configuration is applied everywhere.

Configure Databricks deployment to be compatible with Confidential Computing

Follow these guidelines:

Delete existing workspace
- If you have already deployed Databricks using deploy_common phase, the first step is to delete the current workspace before redeploying it with the correct configuration for Confidential Computing.
- Go to the Azure dashboard and navigate to the resource group where your Databricks workspace is located (usually the common resource group used in the initial deployment).
- Select the Databricks workspace resource and delete it.
Set up the environment for Confidential Computing
- Once the workspace is deleted, you need to adjust the configuration variables to make the new deployment compatible with Confidential Computing. Add the following variables to the environment configuration:
```
databricks_enhanced_security_compliance: false
databricks:
  cluster:
    node_type_id: "Standard_DC8as_v5"
```
Explanation of the variables
- databricks_enhanced_security_compliance: Set to false to avoid additional security compliance configurations that are not needed in this context, and to remove the ability to use confidential type machines.
- databricks.cluster.node_type_id: This is configured, for example, as “Standard_DC8as_v5”, which is a Confidential Computing node type in Azure.
Deploying the workspace with the new configuration
- To deploy Databricks, we need to re-run the deploy_common phase with the new configuration.
- Once the deployment is complete, the Databricks workspace will be configured to use Confidential Computing nodes.
- To configure the Databricks job we must run again the deploy_core.