Configure your releases
This section group guidelines with the specific configuration required by an OB for installing a particular Aura version
This is the multi-page printable view of this section. Click here to print.
This section group guidelines with the specific configuration required by an OB for installing a particular Aura version
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.
Python repositories migration for PyUtils, Aura NLP, Aura Complex Logic Framework plugin packages and ATRIA repositories.
Migration of Python repositories from Python 3.9 to Python 3.13 version for PyUtils, Aura NLP, Aura Complex Logic Framework plugin packages and ATRIA repositories
This document describes the migration process of Python repositories from Python 3.9 to Python 3.13 1 for PyUtils, Aura NLP, Aura Complex Logic Framework plugin packages, ATRIA and other productive Python repositories that has taken place in Prince 10.0.0 release.
This migration is required due to the end of life of Python 3.9, set in October 2025.
PyUtils contains multiple repositories that have been migrated to Python 3.13 version by Aura Global NLP Team.
The use of these libraries is the same as before the migration, but OBs constructors must test the use cases to ensure that everything is working correctly.
The Aura Global NLP team has migrated the Python repositories to Python 3.13 version and has generated the different NLP packages for the OBs.
Two branches will live together:
The release/8.0 branch will be launched together with Prince 10.0.0 delivery. However, release/7.0 will remain active until the OB deploys Prince in production environment and even after that, for any issue or hotfix required.
The repositories of NLP training has a JenkinsFile 2 that defines the pipeline in Jenkins for the continuous integration of the repositories. For release/7.0 branch, the JenkinsFile of Aura NLP repositories will be configured for working with Python 3.9 version in the pipelines defines in Jenkins, to allow OBs to continue creating NLP packages, until they deploy this new release.
When deploying Prince release and changing from release/7.0 to release/8.0, both branches must be synchronized to preserve all modifications made in the older one.
Constructors should not do any change, as no trainings with the QnA and LUIS stages should exist (these stages are deprecated and must have already been replaced by the OpenAIEmbeddings and CLU stages respectively).
With the NLP packages provided by Aura Global NLP team, the OB constructors must test and validate that all the use cases are working correctly.
The QnA and LUIS recognizers are deprecated and have been replaced by the OpenAIEmbeddings and CLU recognizers respectively in all trainings.
The repositories resources listed below, which are the ones in production environment, have been migrated:
The Aura Global NLP team and constructors have carried out the following steps for the migration of CLF plugins:
requirements.txt the packages to the versions generated for Prince release.Currently, there are no constructors outside the global team. For this reason, the Aura Global NLP team will be responsible for the migration of the CLF Plugins.
Below, the list of migrated CLF plugins repositories is included:
The ATRIA repositories have been migrated to Python 3.13 by Aura Global Team.
The configuration inside ATRIA repositories must be the same as before migration, but constructors must test the use cases to ensure that everything is working correctly.
Get sure that any productive repository that is not currently being used has been migrated from Python 3.9 to 3.13 version before being put into production.
Modifications in Aura components associated to the update of Nodejs in release Prince 10.0.0 that must be carried out by the OBs when deploying this version
The following dependencies of Aura Nodejs components have been updated in Prince 10.0.0 release.
This affects aura-bot and, consequently, implies that different tasks must be done by the OBs in order to make their dialogs compatible with these modifications.
Changes in the rest of components do not affect neither the constructors nor the deployment itself.
In Prince release, Nodejs has been updated to Nodejs 22 version.
This upgrade does not need any additional task to be executed by the OB use cases developers.
In Prince release, Typescript has been updated to Typescript 5.8.2.
Prior to deploying Prince, OBs should update these versions in the package.json:
This upgrade could generate certain errors listed below. In these scenarios, OBs constructors can resolve these problems with the indicated solution:
"suppressImplicitAnyIndexErrors": true in tsconfig.json
super.initialDialogId
this.initialDialogIdthis.addDialogIn Prince release, Bot Framework has been updated to Bot Framework 4.23.2 version.
Prior to deploying Prince, OBs should update these dependencies, if they are needed by the local dialogs:
In Prince release, Aura uses the latest Superagent version 10.2.0.
Prior to deploying Prince, OBs constructors should update these versions in the package.json:
{
"name": "@telefonica/aura-bot-generic-library",
"version": "10.0.0",
"repository": {
"type": "git",
"url": "git@github.com:Telefonica/aura-bot-libraries.git",
"directory": "packages/generic"
},
"license": "UNLICENSED",
"main": "lib/index.js",
"scripts": {},
"dependencies": {
"@telefonica/aura-bot-utilities": "2.0.0",
"@telefonica/aura-clients": "2.0.0",
"@telefonica/aura-logging": "6.0.0",
"@telefonica/aura-utilities": "2.0.0",
"botbuilder": "~4.23.2",
"botbuilder-dialogs": "~4.23.2",
"superagent": "^10.2.0",
"joi": "^17.6.0"
},
"devDependencies": {
"@telefonica/aura-locale-importer": "9.30.0",
"@telefonica/eslint-config-aura": "2.14.0",
"@types/chai": "^4.2.3",
"@types/jsonwebtoken": "^9.0.1",
"@types/mocha": "^10.0.1",
"@types/node": "^18.16.0",
"@types/sinon": "^10.0.14",
"@types/superagent": "^8.1.9",
"@typescript-eslint/eslint-plugin": "^5.57.0",
"@typescript-eslint/parser": "^5.57.0",
"chai": "^4.3.10",
"cross-env": "^5.2.0",
"eslint": "^8.36.0",
"eslint-plugin-import": "^2.27.5",
"eslint-plugin-jsdoc": "^40.1.0",
"mocha": "^10.2.0",
"mocha-jenkins-reporter": "^0.4.8",
"mocha-sonarqube-reporter": "^1.0.2",
"nyc": "^15.1.0",
"shx": "^0.3.3",
"sinon": "^15.0.4",
"ts-node": "^10.9.1",
"tslint": "~5.18.0",
"typescript": "~5.8.2"
},
"engines": {
"node": ">=18.0.0"
},
"plugin": {
"provides": [
"generic"
]
}
}
In releases previous to Nodoubt 9.11.0, it is required to update the CLU API used for the clu-storage
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.
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>
Requisites for the proper operation of Nodoubt 9.11.0 release
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.jsonavro/sizeReportDefault.jsonDescription of the workaround required for Metallica release, that implies the restart of ATRIA components
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.
Guidelines to update Kiss base configuration:
aura-avro-adapter.json configuration for aura-kpis-uploader in the Azure common storage.<YOUR_ENV> with the corresponding environment: es-pre, es-pro, br-pre, de-pre, de-int, etc.output_install/<YOUR_ENV>_info.json) to get:
<AURA_KPI_CONTAINER> value.<AURA_KPI_CONTAINER> with the obtained value.<AURA_MICROSOFT_AZURE_STORAGE_COMMON_ACCOUNT> with the obtained value.<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)
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.
Guidelines to update Imagine Dragons base configuration:
aura-bot and aura-billing Kernel clients, and use them in Databricks executionsaura-bot and aura-billing clients.<YOUR_ENV> with the corresponding environment: es-pre, es-pro, br-pre, de-pre, de-int, etc.output_install/<YOUR_ENV>_info.json) to get:
<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)
Add these scopes in the Kernel app of aura-bot:
admin:datasets:readdata:readdata:writeAdd these scopes in the Kernel app of aura-bot.
admin:datasets:readdata:readdata:writeIt 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"
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
Guidelines to update Germany default configuration for Imagine Dragons:
aura-bot client.AURA_CONVERSATIONS container in Kernel Azure Storage.<YOUR_ENV> with the corresponding pre-production environment: es-pre, es-cert, br-pre, de-pre, de-int, etc.output_install/<YOUR_ENV>_info.json) to get:
<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)
Connect to the environment using your kubeconfig.
Edit the config-map of aura-configuration-api to include the new brand.
<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>
...
kubectl -n <YOUR_ENV> rollout restart aura-configuration-api
<UUID> with a valid UUID version 4 generated for every request.<AURA_API_KEY> with the Aura API key read from the environment installation file.<CHANNEL_ID> with the channel to be configured.<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>"
}'
PATCH should be executed twice, at least, once per existing channel:
<UUID> with a valid UUID version 4 generated for every request.<AURA_API_KEY> with the Aura APIKey read from the environment installation file.<APPLICATION_ID> with the application to be configured.<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>"
}'
PATCH should be executed once, at least, to update ATRIA application:
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
https://api.de-int-whatsappsim.baikalplatform.comhttps://api.de-pre-whatsappsim.baikalplatform.comhttps://api.de-pro-whatsappsim.baikalplatform.comAURA_MICROSOFT_AZURE_STORAGE_CONTAINER_DESTINATION and AURA_MICROSOFT_AZURE_STORAGE_ACCESS_KEY_DESTINATION belong to the corresponding Kernel deployment.deploy_core to assure that the configuration is applied everywhere.Follow these guidelines:
Delete existing workspace
deploy_common phase, the first step is to delete the current workspace before redeploying it with the correct configuration for Confidential Computing.Set up the environment for Confidential Computing
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
deploy_common phase with the new configuration.deploy_core.