Skip to content

Koldan Migration Guide

7.0 -> 7.1

Support System Browser Flow

In version 7.0.11 we added support for System Browser Flow (See issue: #287). Over time this should become the default functionality or at least configurable at the site level. To make this happen:

  1. The new valid redirect uri needs to be added to the koldan-grpc oidc client: httpX://koldan.org.arpa:8193/appredirect.html
  2. We must have configured keycloak advertise address that is accessible from end user machines
  3. We need to ensure that our web console and keycloak are accessible from end user machines

Keycloak Upgrade

We upgraded Keycloak from 24.0.5 to 26.0.4.

Windows

The upgrade steps are:

  1. Stop Keycloak service
  2. Backup Keycloak directory and Database
  3. Remove all files from keycloak directory, BUT: service and conf.
  4. Extract files from new keycloak version BUT conf directory
  5. Start Keycloak service

Helm

TBD

SherpWrap Config

K2 engine is now using SherpWrap instead of using Shepra directly. Therefore, the engine sherepa config is now unified OnlineConfig.

We mostly didn't configure anything but defaults, but if needed, now its all configurable, i.e:

koldan:
  k2:
    config:
      extraSilence: 0.6
      batchSize: 24
      maxActive: 3000
      numThreads: 4
      decodingMethod: "modified_beam_search"
      maxActivePaths: 4
      lmScale: 0.5
      modelType: "zipformer"
      provider: "cpu"
      deviceId: 0

Note that currently, better to specify modelType manually, depends on the used model type.

For more details about OnlineConfig, go to SherpWrap configurations or consult with Dixilang support team.

Hotwords

Engine K2 hotwords new config structure on windows:

for exmaple: application-engine-medical.yaml

koldan:
  k2:
    config:
      hotWords: 
        enabled: true
        file: config\medical-hotwords.txt

gRPC SSL

Until this version, gRPC SSL had its own settings, regardless of spring SSL context and has only PEM supported.

In v7.1 we made 2 changes:

  1. We now also support PKCS12 for gRPC certificates
  2. Spring SSL Context can be used if needed, thus saving duplicate configurations

New Configuration Form

The new configuration form (KoldanSSLProperties):

Property Default Description
koldan.grpc.ssl.enabled false Whether to enable SSL on gRPC Service
koldan.grpc.ssl.useSpringSSLContext false When true, all other settings from koldan.grpc.ssl.* will be ignored (including enabled) and we will use same SSL settings that spring constructs. Fit to installations where the Web and gRPC have same certificate
koldan.grpc.ssl.key-store - Location of PCKS12 keystore file, if keystore type is PCKS12
koldan.grpc.ssl.key-store-password - Password for PCKS12 key store, if keystore type is PCKS12
koldan.grpc.ssl.key-store-type PKCS12 Keystore type, could be PCKS12 or PEM
koldan.grpc.ssl.key-file - Location of PEM key file, if keystore type is PEM
koldan.grpc.ssl.cert-file - Location of PEM certificate file, if keystore type is PEM

Examples

Use spring certificate

If certificate already defined in spring context (server.ssl.*), use it automatically.

koldan:
  grpc:
    ssl:
      useSpringSSLContext: true
Use PCKS12 keystore

If we got PCKS12 keystore from customer, we can use it for gRPC, i.e:

koldan:
  grpc:
    ssl:
      enabled: true
      key-store: /path/to/keystore.p7b
      key-store-password: MyP@ssw0rd
      key-store-type: PKCS12
Use PEM's

If we have the certificate and the private key in PEM format, we can use it, i.e:

koldan:
  grpc:
    ssl:
      enabled: true
      key-file: mykey.pem
      cert-file: mycert.pem
      key-store-type: PEM

7.1 -> 8.0

See v8 Migration Guide

8.X -> 9.0

  • TODO: engine oidc clients should have role "koldan-engine" (will be mapped to new engine role)