Home
MATRIXX Configuration
Configuring MATRIXX Using Helm
Configure MATRIXX by adding values for properties from the MATRIXX Helm chart in your Helm values file. The MATRIXX Helm chart includes component sub-charts in a hierarchy of reusable components.
MATRIXX Helm Chart Properties
The MATRIXX Helm chart, and by extension a cloud native MATRIXX deployment, are configured using a Helm values file or files.
Utility Configuration
The Helm chart includes utilities for deleting old transaction logs and setting up the Event Repository. You can run these utilities directly or scheduled using the MATRIXX Helm chart.
One-Time Utility Execution
Run the delete_old_transaction_log.py script as a one-time job using the execute_on_pod.sh script in the MATRIXX Toolbox image and the docker run command.

Welcome
MATRIXX Release Notes
MATRIXX Architecture
MATRIXX Installation and Upgrade
MATRIXX Configuration
- About MATRIXX Configuration
  MATRIXX Configuration describes the tasks required to configure MATRIXX components.
- Configuring MATRIXX Using Helm
  Configure MATRIXX by adding values for properties from the MATRIXX Helm chart in your Helm values file. The MATRIXX Helm chart includes component sub-charts in a hierarchy of reusable components.
  - Managing Helm Values Files
    In complex installations it may be necessary or helpful to use more than one Helm values file. The helm install and helm upgrade commands can accept multiple values files, with values in files listed later taking precedence. Layering Helm values files in this way can be used to reduce duplication.
  - MATRIXX Helm Chart Properties
    The MATRIXX Helm chart, and by extension a cloud native MATRIXX deployment, are configured using a Helm values file or files.
    - Image Repository Configuration
      docker_kubernetes/c_config_helm_docker_repo.html#c_config_helm_docker_repo__table_uzz_xhk_xlb describes the properties that configure access to the image repository hosting the MATRIXX images at your site. These are defined at the global level so that they are available to all sub-charts.
    - Domain, Sub-Domain, and Engine Topology Configuration
      docker_kubernetes/c_config_helm_subd_eng_topo.html#c_config_helm_subd_eng_topo__table_x1n_tfl_xlb describes properties defining sub-domains and MATRIXX Engine topology.
    - Naming and Grouping
      MATRIXX Engine components, for example, engine 1 in sub-domain 1 (s1e1), can only be deployed once per namespace.
    - Network Enabler Topology Configuration
      A Statefulset is used to create Network Enabler pods, and NE pods are not dependent on the domain level. Network Enabler pods can connect to CAMEL Gateway pods regardless of domains or sub-domains.
    - Site-Level Traffic Routing Agent Configuration Topology
      docker_kubernetes/c_config_helm_tra_topo.html#concept_ar3_45n_yqb__table_nnk_14l_xlb describes site-level Traffic Routing Agent (TRA) Helm chart properties.
    - Features Configuration
      docker_kubernetes/c_config_helm_features.html#c_config_helm_features__table_nnk_14l_xlb describes the properties for declaring a feature or capability is available in the deployment as a whole even if it is not deployed as part of a single chart release. For example, a Helm chart release might be used to install only MATRIXX Engine, but that chart must include global.features.payments set to true to direct the engine to use an existing Payment Service.
    - Pricing Configuration
      Pricing information can be updated from a configuration source. docker_kubernetes/c_conf_sources_pricing.html#c_conf_sources_pricing__table_xzh_tpc_nqb describes the available configuration properties.
    - Networking Configuration
      External Address properties for components in a separate cluster can be expressed as IP addresses or fully qualified domain names (FQDNs).
    - Services Configuration
      docker_kubernetes/c_config_helm_svcs.html#c_config_helm_svcs__table_nnk_14l_xlb describes the property used to specify whether network traffic is sent to endpoints on the same node or allowed to be sent to other endpoints in the cluster.
    - Monitoring Configuration
      docker_kubernetes/c_config_helm_monitoring.html#c_config_helm_monitoring__table_rtd_m4l_xlb describes global configuration properties related to the monitoring of MATRIXX.
    - Shared Storage Configuration
      The Helm chart can be configured to create a root directory for shared storage, shared storage for core dumps from MATRIXX Engine, Traffic Routing Agent (TRA), fast shared storage for MATRIXX Engine, and shared storage for TRA route-cache checkpointing data.
    - Distributed Tracing Configuration
      Distributed tracing allows information about requests flowing between components to be recorded in a central place. This information can then be queried to find out the health of the system, individual components, or individual requests. The Cloud Native Computing Foundation (CNCF) standard for collecting this trace information is called OpenTelemetry.
    - Log Aggregation Configuration
      docker_kubernetes/c_config_helm_log_ag.html#c_config_helm_log_ag__table_jl3_xsv_ypb describes global configuration properties related to deploying and configuring the Fluent Bit data collector to tail MATRIXX log files. For Fluent Bit default values, see the Fluent Bit documentation.
    - Version Pinning Configuration
      In the process of upgrading MATRIXX to a new version, upgraded MATRIXX gateways and web apps are communicating with MATRIXX Engines that have yet to be upgraded. This is facilitated by constraining or pinning the gateways and web apps to the schema versions you are upgrading from until you are ready for them to use the upgraded schema versions.
    - MongoDB Event Loader Configuration
      MongoDB configuration is required when Event Loader is enabled. docker_kubernetes/c_config_helm_mongodb.html#c_config_helm_mongodb__table_zhl_xwl_xlb describes the MongoDB configuration properties.
    - Ingress Controller
      docker_kubernetes/c_config_helm_ingress_ctrl.html#c_config_helm_ingress_ctrl__table_zhl_xwl_xlb describes the properties for specifying the ingress controller in use. This adds required annotations to ingress objects, including session affinity. It does not cause installation of any specific ingress controller components or configuration. In this release, the only supported implementation is Nginx.
    - Proxy Ingress and Load Balancer Configuration
      docker_kubernetes/c_config_helm_proxy_ingress.html#c_config_helm_proxy_ingress__table_zhl_xwl_xlb describes the properties used to configure an Ingress for the RS Gateway, My MATRIXX, and MATRIXX Backoffice Customer Tool web apps.
    - Time Zone Configuration
      docker_kubernetes/c_config_helm_timezone.html#c_config_helm_timezone__table_es1_ltl_xlb describes the configuration properties that can be used to change the time zone of MATRIXX pods from the UTC default, in case the time zone must be different from the underlying cluster.
    - Liveness and Readiness Probe Configuration
      For each MATRIXX Engine and Traffic Routing Agent (TRA-PROC and TRA-PUB) pod, you can override liveness and readiness probe settings.
    - Pod Label Configuration
      Pods can be labeled globally using the global.labels.podLabels property and per-component using a sub_chart_name.label.podLabels configuration property. Labels added globally are added to all pods in the installation. Labels defined for a specific component are added to pods deployed by that sub-chart, in addition to any globally defined labels.
    - Annotation Configuration
      Annotations are for use in attaching arbitrary, non-identifying metadata to objects.
    - Init Container Configuration
      Pods might be created with init containers responsible for loading configuration or performing pre-requisite checks. These containers are based on the matrixx-sideloader and matrixx-toolbox images and might require increased resources in certain circumstances.
    - Miscellaneous Configuration
      docker_kubernetes/c_config_helm_misc.html#c_config_helm_misc__table_zhl_xwl_xlb describes miscellaneous properties available to multiple sub-charts.
    - Utility Configuration
      The Helm chart includes utilities for deleting old transaction logs and setting up the Event Repository. You can run these utilities directly or scheduled using the MATRIXX Helm chart.
      - Delete Old Transaction Logs Utility
        The Delete Old Transaction Logs utility is a cron job that runs the delete_old_transaction_log.py script with specified options on a regular schedule. There is one version of this job created for each MATRIXX Engine. docker_kubernetes/c_config_helm_utilities_deletelogs.html#c_config_helm_utilities_deletelogs__table_zhl_xwl_xlb describes the available configuration properties.
      - Initialize the Event Repository Utility
        If the global.features.eventLoader configuration property is set to true, the initialize Event Repository utility is created as a single-use job that uses a ready processing pod to set up the Event Repository. The job must also be enabled with the utilities.initialize-event-repository.enabled property. docker_kubernetes/c_config_helm_utilities_initrepository.html#c_config_helm_utilities_initrepository__table_qpm_q1n_j4b describes the available configuration properties.
      - One-Time Utility Execution
        Run the delete_old_transaction_log.py script as a one-time job using the execute_on_pod.sh script in the MATRIXX Toolbox image and the docker run command.
  - Topology Operator Configuration
    For information about Topology Operator configuration, including Topology Operator-related health checking, pricing, tax, and multi-tenancy configuration, see the discussion about Topology Operator configuration in MATRIXX Installation and Upgrade.
  - Common Sub-Chart Properties
    Each MATRIXX component has an corresponding Helm sub-chart that can be configured from the main chart.
  - Component-Specific Sub-Chart Properties
    Each MATRIXX Helm sub-chart has component-specific properties.
- Configuring MATRIXX Engine
  MATRIXX Engine configuration can be applied from a configuration source.
- Configuring Traffic Routing Agent
  Traffic Routing Agent (TRA) configuration can be added to the deployment with a configuration source.
- Configuring Sub-Domain Routing (Multiple Sub-domains)
  In a MATRIXX environment where multiple customer sub-domains are implemented in separate engine chains, you configure sub-domain routing so that traffic is directed to the correct customer sub-domain where the subscriber is homed. You must configure different components across MATRIXX for sub-domain routing to work.
- Example Single Domain Deployments
  Example configurations are provided for single-engine, dual-engine, and dual-engine with Traffic Routing Agent in disaster recovery mode (TRA-DR) cloud native MATRIXX examples.
- Configuring MATRIXX Gateways and Web Apps
  In a non-containerized installation of MATRIXX, configure MATRIXX gateways and web apps using files in the /opt/mtx/conf directory in the pod(s) hosting those components. In a cloud native deployment, configuration files can be provided in the /opt/mtx/conf directory of the component container(s) using the following methods:
- Configuring CDR Processing
  The MATRIXX Engine can import and rate Solution42® call detail records (CDRs) and generate MATRIXX Event Detail Records (EDRs) from them. Generally, this is used only when integrating with an Oracle BRM system. Other projects should use external mediation to convert external CDRs into Diameter messages for MATRIXX processing.
- Configuration Input Settings
  In a cloud native MATRIXX installation, MATRIXX Engine configuration specified in the create_config.info file is applied with a configuration source. This file contains a list of the questions asked by the configuration script during the configuration process and the answers provided by the administrator. Each question sets a configuration parameter. The engine(s) are configured with these parameters with a helm upgrade command.
MATRIXX Security
MATRIXX Integration
MATRIXX Diameter Integration
MATRIXX Call Control Framework Integration
MATRIXX TM Forum Integration
MATRIXX 5G Integration
MATRIXX 5G Event Streaming
MATRIXX Event Streaming
MATRIXX Administration
MATRIXX Web App Administration
MATRIXX Monitoring and Logging
MATRIXX Policy
MATRIXX Kafka CDR Consumer
MATRIXX Pricing and Rating
MATRIXX Pay Now
MATRIXX Subscriber Management
MATRIXX Subscriber Management API
MATRIXX Business API SDK
My MATRIXX Help
MATRIXX Backoffice Customer Tool Help
MATRIXX Third-Party Licenses
Glossary

One-Time Utility Execution

Run the delete_old_transaction_log.py script as a one-time job using the execute_on_pod.sh script in the MATRIXX Toolbox image and the docker run command.

The following example runs delete_old_transaction_log.py on a publishing pod selected at random from the pods in engine 1, sub-domain 1. The execute_on_pod.sh script makes 5 attempts to find a ready pod, pausing for 5 seconds between each attempt.

docker run --rm your_image_repository/matrixx-toolbox:version ./execute_on_pod.sh --mode random --labels mtx-class=engine,mtx-type=publ,engine=1,subdomain=1 --max-attempts 5 --sleep-time 15 su - mtx -c "delete_old_transaction_logs.py"

The following example initializes the Event Repository (outside of the Helm chart) on a ready pod chosen at random from the ready pods available on a mtx-0.mtx-svc.mongodb.svc.cluster.local host.

docker run --rm your_image_repository/matrixx-toolbox:version ./initialize_mongodb.sh --host mtx-0.mtx-svc.mongodb.svc.cluster.local --user admin --password password123

For more information about the execute_on_pod.sh script and other available utilities, see the discussion about the MATRIXX Toolbox image in MATRIXX Integration.