New Cloud Native Features

Simplified Persistent Storage Requirements for ECE Cloud Native

ECE cloud native reduces its dependency on ReadWriteMany (RWX) persistent storage and uses storage based on the requirements of each workload.

ECE cloud native includes the following changes:

Persistent storage for logs is optional. To use persistent storage for ECE logs, configure pvc.logs.name. If you do not configure a logs PVC, ECE component logs are written to the console instead. You can also view these logs by using the kubectl logs command.
Some utilities and logging features continue to write files to the logs directory. These include query.sh, subscriber tracing, GC logging, CreateJmsNotificationQueue.sh, and SyCacheMigration.sh. These logs are not available from the console. When a logs PVC is not configured, the files are stored in pod-local storage and are not persistent. They are lost if the pod crashes or restarts.

Configure a logs PVC if you need to retain file-based logs.
brmconfig-pvc uses ReadWriteOncePod storage. ECE uses this volume to store the payloadconfig_ece_sync_*.xml files generated by Pricing Updater. These files are retained if the pod restarts.
ECE no longer uses sdk-pvc. The ECE SDK remains available at /home/charging/opt/ECE/ocecesdk, but the directory is no longer backed by a dedicated persistent volume. SDK-generated class files, logs, and other runtime files are pod-local by default. If you need to preserve SDK-generated files, copy them to the logs location on logs-pvc.
ECE no longer uses external-pvc. The /home/charging/ext directory remains available for supported non-SSL custom files, but it is no longer backed by a persistent volume. Add these files to your ECE container image by using image layering. Configure SSL wallets and keystores by using the supported Kubernetes secret-based configuration.
cdrformatter-pvc continues to require RWX storage. CDR Formatter output requires a shared writable location, so its persistent storage requirement is unchanged.

These changes reduce the need for shared RWX storage and provide greater flexibility when deploying ECE in Kubernetes environments where RWX storage is not available for every workload.

For more information, see "About Elastic Charging Engine Volume Mounts" in BRM Cloud Native Deployment Guide.

Pod-Local Wallet Storage for ECE

ECE no longer uses ece-wallet-pvc for wallet storage. Instead, ECE stores wallets in pod-local emptyDir storage. When a wallet-using pod starts, ECE creates the wallet under /home/charging/wallet by using the credentials from the mounted Kubernetes secrets. If Kubernetes re-creates the pod, ECE re-creates the wallet from the current secret values.

For long-running wallet-using pods, the wallet-watcher sidecar container monitors the mounted secrets for credential changes. When you update a secret, wallet-watcher updates the corresponding wallet in the pod. ECE then detects the updated wallet credentials and refreshes or re-creates the affected connection objects so that they use the new credentials without requiring a routine pod restart.

Removing ece-wallet-pvc eliminates the requirement for shared persistent wallet storage. Wallets are created from Kubernetes secrets when pods start and are updated when the corresponding secret credentials change, enabling ECE to use updated credentials without routine pod restarts during credential rotation.

For more information, see "About Elastic Charging Engine Volume Mounts" in BRM Cloud Native Deployment Guide.

Enhanced TLS Wallet Management in BRM Cloud Native

BRM cloud native now provides enhanced management of TLS wallets and certificates. BRM container images no longer include populated TLS wallets, private keys, or sample certificate authority (CA) certificates. When you enable TLS, you provide certificates and trust material that your organization approves. You manage these items throughout their life cycle.

You can provide TLS wallets by using external Kubernetes Secrets or by adding the wallet files to the BRM cloud native Helm chart. BRM supports component-specific wallet secrets and a shared wallet secret. When multiple wallet sources are available, a component-specific wallet takes precedence over the shared wallet sources. When you enable TLS, you must provide a supported wallet source. Otherwise, the Helm chart installation fails.

This release also includes the following TLS wallet enhancements:

You can configure one-way or two-way TLS by using the ocbrm.sslMode key.
You can use extUserSSLWalletSecret to provide a component-specific TLS wallet and ocbrm.extCustomSSLWalletSecret to provide a shared TLS wallet.
BRM stores the root-key wallet in the database instead of including it in container images or pods.
BRM no longer supports the ocbrm.customSSLWallet key.

For more information, see "Managing Wallet and KeyStore Certificates" in BRM Cloud Native Deployment Guide. Also see "Using External Kubernetes Secrets for Certificates and Wallets" in BRM Cloud Native System Administrator's Guide.

Enhanced Oracle RAC Configuration for BRM Cloud Native

BRM cloud native now provides enhanced configuration support for Oracle Real Application Clusters (Oracle RAC) databases. You can configure Oracle RAC database connection details in the Helm chart values without modifying the BRM cloud native Helm chart templates.

This release includes the following Oracle RAC configuration enhancements:

You can use ocbrm.db.tnsAdmin.connectionDescriptor to provide a custom Oracle Net connection descriptor for the primary BRM schema. For multischema deployments, you can use ocbrm.db.multiSchemas.secondaryN.tnsAdmin.connectionDescriptor to provide a connection descriptor for each secondary schema.
You can use ocbrm.db.tnsAdmin.sqlnet to override the generated sqlnet.ora configuration when your database configuration requires custom Oracle Net settings.
BRM uses the configured database service name in the DM Oracle and DM Invoice configurations. In multischema deployments, each secondary DM Oracle configuration uses the service that you configure for its corresponding schema.
Rated Event Manager (REM) uses the same primary and secondary connection descriptors to construct its JDBC connection URLs. You do not need to configure separate Oracle RAC-specific JDBC URL overrides for REM.
If you do not configure the new connection descriptor or SQLnet values, BRM continues to generate the existing TCP or TCPS database connection configuration. Existing deployments do not need to add the new configuration values.

These enhancements give you greater flexibility when you configure BRM cloud native deployments with Oracle RAC, including RAC address lists and schema-specific database services, while BRM preserves the existing database configuration behavior when you do not use the new overrides.

For more information, see "Configuring the BRM Server" in BRM Cloud Native Deployment Guide.

Direct Loading of Rated Events

ECE cloud native now configures Rated Event Formatter (REF) to use the ECE Rated Event Manager (REM) plug-in in DIRECT mode by default. This enables ECE to load rated events directly into the BRM database.

To use direct loading, set the REFPluginConfiguration.jdbcConfigurations.connectionURL property in override-values.yaml or values.yaml to a valid BRM database URL.

For more information, see "Configuring Direct Loading Using the ECE RE Manager Plug-in" in BRM Cloud Native Deployment Guide.

ECE Cloud Native Can Now Refresh Runtime Persistence Database Passwords

In ECE cloud native deployments, you can now rotate persistence database passwords at runtime without restarting ECE pods.

When you update a persistence database password in a Kubernetes secret, the ECE wallet sidecar updates the credential in the pod-local ECE wallet. If there is a database connection failure with the previous password, ECE reads the current password from the wallet, updates the connection pool, and retries the connection once.

Persistence upgrade jobs do not use the runtime password-refresh mechanism. They use the schema-specific database credentials that are available to the job when it starts.

For more information, see "Rotating Persistence Database Passwords" in BRM Cloud Native System Administrator's Guide.

ECE Cloud Native Now Refreshes Kafka and JMS Connections After Credential Rotation

In ECE cloud native deployments, ECE can refresh Kafka and JMS connections after credential rotation without requiring routine ECE pod restarts.

When updated credentials propagate to the ECE wallet and an existing Kafka or JMS connection fails because its credentials are stale, ECE refreshes or re-creates the affected connection resources using the current wallet credentials.

For Kafka, ECE refreshes the affected producer and retries the failed operation once. For Kafka consumers, ECE re-creates the affected consumer after a polling failure and retries the poll once.
JMS reconnects according to the configured connection retry count and retry interval.

No new configuration is required. Existing Kubernetes secret, wallet-watcher, Kafka, JMS, and connection retry configurations continue to apply.

This enhancement reduces operational disruption during credential rotation and enables ECE to recover from stale Kafka and JMS credentials without requiring a routine pod restart.

For more information, see "Rotating Kafka and JMS Credentials at Runtime" in BRM Cloud Native System Administrator's Guide.

Upgrade Consideration for Existing REF JDBC Configurations

If you upgrade an existing ECE cloud native deployment that uses Rated Event Formatter (REF) direct loading, update your REF JDBC configuration. Use the REFPluginConfiguration.jdbcConfigurations key in your override-values.yaml file. Configure one JDBC connection entry for each BRM database schema.

For information about updating your configuration during an upgrade, see "Upgrading Your ECE Cloud Native Services" in BRM Cloud Native Deployment Guide.

1 New Cloud Native Features

New Features in Cloud Native 16.26.0