5 Parameter Updates for OCNADD Microservices

The following sections describe the procedure to update the container images of consumer adapter and egress gateway services by updating the admin service yaml file.

Note:

There could be a potential data loss during parameter modification. Hence, any such activity must be planned in a maintenance window.

5.1 Updating Consumer Adapter Parameters

Note:

In case of an upgrade, rollback, service restart, or configuration is created with the same name, duplicate messages will be sent by the adapter service to avoid data loss.

The consumer adapter service update can be performed for any of the following:

  1. Enabling Egress Annotation
  2. The Egress Adapter Service image changes
  3. HPA configuration changes
  4. Egress Adapter Service parameters changes

Enabling Egress Annotation

Note:

Skip this procedure if CNLB based OCCNE cluster is used.

Egress annotation is required for traffic from OCNADD to be routed outside the cluster. The user needs to enable the following parameter in the corresponding ocnadd-custom-values.yaml and perform the upgrade procedure with respect to the deployment mode.

ocnaddadmin.ocnadd.admin.env.OCNADD_EGRESS_NETWORK_ENABLE: true

Users can update the below parameters according to the network:

Table 5-1 Egress Annotation Parameters

Parameter Name Data Type Range Default Value Mandatory(M)/Optional(O)/Conditional(C) Description
OCNADD_EGRESS_NETWORK_NAME_VALUE STRING - oam O Name of the egress network configured in the CNE cluster
OCNADD_CNC_ENABLE STRING - true O Enable oracle.com.cnc network

When DD is in Centralized deployment mode:

  • The consumer adapters can be associated with:
    • Default worker group deployment (possible only when the DD was upgraded from earlier supported releases to the 23.4.x release in Centralized deployment mode)

    • With one or more worker group deployments (from release 25.1.0, kubectl-hns must be installed when worker groups are required; by default, the deployment will use the "Default" worker group).

  • The parameters are always updated using the management group helm charts and custom values file.
  • The parameters upgrade can be performed for one or more or all worker groups at the same time.

For the parameters details see "Admin Service Parameters" section in "Customizing OCNADD" chapter of Oracle Communications Network Analytics Data Director Installation, Upgrade, and Fault Recovery Guide.

  1. Update the required parameters in custom values used for the management group.
  2. Update the parameter global.env.admin.OCNADD_UPGRADE_WG_NS with the namespaces of the worker groups in which the adapter parameters need to be updated.

    For example:

    1. For Default worker group deployment:
       global.env.admin.OCNADD_UPGRADE_WG_NS=ocnadd-deploy               ##---> update it with the ocnadd-namespace or the default worker group namespace for example ocnadd-deploy
    2. For one or more worker groups:
      global.env.admin.OCNADD_UPGRADE_WG_NS=dd-worker-group1            ##---> update it with the worker group namespace for example dd-worker-group1

    If the adapter parameters need to be updated in all the worker group, then all the worker group namespaces can be provided separated by comma.

    For example:

    global.env.admin.OCNADD_UPGRADE_WG_NS=dd-worker-group1,dd-worker-group2
  3. After updating the parameters based on requirements, run the following command to apply the changes:
    helm upgrade <release-name> -f ocnadd-custom-values.yaml --namespace <ocnadd-namespace> <helm_chart> --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true

    where,

    <release_name> is the release name of the management group.

    ocnadd-custom-values.yaml is the custom values file used to deploy the management group.

    <ocnadd-namespace> is the namespace of the management group or the default worker group namespace.

    <helm_chart> is the helm chart folder of the management group.

    For example:

    1. For Default worker group deployment:
      helm upgrade ocnadd-mgmt -f ocnadd-custom-values.yaml --namespace ocnadd-deploy ocnadd_mgmt --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true
    2. For one or more worker group:
      helm upgrade ocnadd-mgmt -f ocnadd-mgmt-custom-values.yaml --namespace dd-mgmt-group ocnadd_mgmt --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true
  4. Use the below command to watch the pod status, all the adapter pods respawn after the upgrade. Check the status of each of the worker groups:
    watch kubectl get po -n <worker-group-namespace-name>
  5. To verify the parameters have been successfully updated, use the below command:
    kubectl describe po <adapter-pod-name> -n <worker-group-namespace-name>

5.2 Updating Correlation Service Parameters

The Correlation service update can be performed for any of the following methods:

  1. Correlation Service image changes
  2. Correlation Service parameters changes

When DD is in Centralized deployment mode:

  • The Correlation service can be associated with
    • Default worker group deployment (possible only when the DD was upgraded from earlier supported releases to the 23.4.x release in Centralized deployment mode).
    • With one or more worker groups deployment
  • The parameters upgrade can be performed for one or more or all worker groups at the same time.

For the parameters details see "Admin Service Parameters" section in "Customizing OCNADD" chapter of Oracle Communications Network Analytics Data Director Installation, Upgrade, and Fault Recovery Guide.

  1. Update the required parameters in custom values used for the management group.
  2. Update the parameter global.env.admin.OCNADD_UPGRADE_WG_NS with the namespaces of the worker groups in which the adapter parameters need to be updated.

    For example:

    1. For Default worker group deployment:
       global.env.admin.OCNADD_UPGRADE_WG_NS=ocnadd-deploy               ##---> update it with the ocnadd-namespace or the default worker group namespace for example ocnadd-deploy
    2. For one or more worker groups:
      global.env.admin.OCNADD_UPGRADE_WG_NS=dd-worker-group1            ##---> update it with the worker group namespace for example dd-worker-group1

    If the adapter parameters need to be updated in all the worker group, then all the worker group namespaces can be provided separated by comma.

    For example:

    global.env.admin.OCNADD_UPGRADE_WG_NS=dd-worker-group1,dd-worker-group2
  3. After updating the parameters based on requirements, run the following command to apply the changes:
    helm upgrade <release-name> -f ocnadd-custom-values.yaml --namespace <ocnadd-namespace> <helm_chart> --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true

    where,

    <release_name> is the release name of the management group.

    ocnadd-custom-values.yaml is the custom values file used to deploy the management group.

    <ocnadd-namespace> is the namespace of the management group or the default worker group namespace.

    <helm_chart> is the helm chart folder of the management group.

    For example:

    1. For Default worker group deployment:
      helm upgrade ocnadd-mgmt -f ocnadd-custom-values.yaml --namespace ocnadd-deploy ocnadd_mgmt --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true
    2. For one or more worker group:
      helm upgrade ocnadd-mgmt -f ocnadd-mgmt-custom-values.yaml --namespace dd-mgmt-group ocnadd_mgmt --set global.env.admin.OCNADD_ADAPTER_UPGRADE_ENABLE=true
  4. Use the below command to watch the pod status, all the adapter pods respawn after the upgrade. Check the status of each of the worker groups:
    watch kubectl get po -n <worker-group-namespace-name>
  5. To verify the parameters have been successfully updated, use the below command:
    kubectl describe po <correlation-pod-name> -n <worker-group-namespace-name>

5.3 Updating Management Group Service Parameters

To update any of the management services parameters follow any of the below procedures based on deployment mode.

When DD is in Centralized deployment mode:

The parameters are always updated using the management group helm charts and custom values file.

For the parameter details, see the section of the respective services in "Customizing OCNADD" chapter of Oracle Communications Network Analytics Data Director Installation, Upgrade, and Fault Recovery Guide.

  1. Update the required parameters in custom values used for the management group.
  2. After updating the parameters based on requirements, run the following command to apply the changes:
    helm upgrade <release-name> -f ocnadd-custom-values.yaml --namespace <ocnadd-namespace> <helm_chart>

    where,

    <release_name> is the release name of the management group.

    ocnadd-custom-values.yaml is the custom values file used to deploy the management group.

    <ocnadd-namespace> is the namespace of the management group or the default worker group namespace.

    <helm_chart> is the helm chart folder of the management group.

    For example:

    1. For Default worker group deployment:
      helm upgrade ocnadd-mgmt -f ocnadd-custom-values.yaml --namespace ocnadd-deploy ocnadd_mgmt
    2. For one or more worker group:
      helm upgrade ocnadd-mgmt -f ocnadd-mgmt-custom-values.yaml --namespace dd-mgmt-group ocnadd_mgmt
  3. Use the below command to watch the pod status, all the adapter pods respawn after the upgrade. Check the status of each of the worker groups:
    watch kubectl get po -n <worker-group-namespace-name>
  4. To verify the parameters have been successfully updated, use the below command:
    kubectl describe po <pod-name> -n <worker-group-namespace-name>

5.4 Upgrading Worker Group Service Parameters

To update any of the worker group services parameters follow any of the below procedures based on deployment mode.

When DD is in Centralized deployment mode:

The parameters are updated using the respective worker group helm charts and custom values file.

For the parameter details, see the section of the respective services in "Customizing OCNADD" chapter of Oracle Communications Network Analytics Data Director Installation, Upgrade, and Fault Recovery Guide.

  1. Update the required parameters in custom values used for the management group.
  2. After updating the parameters based on requirements, run the following command to apply the changes:
    helm upgrade <release-name> -f ocnadd-custom-values.yaml --namespace <ocnadd-namespace> <helm_chart>

    where,

    <release_name> is the release name of the management group.

    ocnadd-custom-values.yaml is the custom values file used to deploy the management group.

    <ocnadd-namespace> is the namespace of the management group or the default worker group namespace.

    <helm_chart> is the helm chart folder of the management group.

    For example:

    1. For Default worker group deployment:
      helm upgrade ocnadd -f ocnadd-custom-values.yaml --namespace ocnadd-deploy ocnadd
    2. For one or more worker group:
      helm upgrade ocnadd-wg1 -f ocnadd-custom-values-wg1-group.yaml --namespace dd-worker-group1 ocnadd_wg1
  3. Use the below command to watch the pod status, the corresponding service pods respawn after the upgrade:
    watch kubectl get po -n <worker-group-namespace-name>
  4. To verify the parameters have been successfully updated, use the below command:
    kubectl describe po <pod-name> -n <worker-group-namespace-name>

5.5 Renewing SSL certificates for OCNADD Services

Certificates Generated Using Script

The renewal of SSL certificate is required when the certificates for OCNADD services get expired or reaches the expiry date.

To renew the certificates using script:
  1. Regenerate the CSR, private key, and secrets for the OCNADD services using the CA certificate and CA key.

    For more information about the certificates, see "Configure SSL or TLS Certificate - Customer Provided CACert and CAKey" section of Oracle Communications Network Analytics Data Director Installation Guide. Make sure to delete the existing "demoCA" folder while running the script.

  2. Get the statefulsets for OCNADD services using the following command:
    kubectl get statefulset-n <namespace-name>
  3. Trigger rolling update for aforementioned services which are listed as statefulsets using following command:
    kubectl rollout restart statefulset <STATEFULSET-NAME> -n <namespace-name>
  4. Get the deployment for OCNADD services by running the following command:
    kubectl get deployment -n <namespace-name>
  5. Trigger rolling update for these services using the following command:
    kubectl rollout restart deployment <DEPLOYMENT-NAME> -n <namespace-name>

Certificates Generated Using OCCM

Oracle Communication Certificate Manager (OCCM) monitors certificate validity and automatically initiates certificate renewal based on the configured renew-before period. Certificates have a lifetime of "days" and are renewed "renewBefore" days before expiry. See "Helm Parameter Configuration for OCCM" section in the Oracle Communications Network Analytics Data Director Installation, Upgrade, and Fault Recovery Guide.

After certificate renewal and prior to the certificate's expiry date, all services need to be restarted at an appropriate time. Follow these steps to restart the services:

  1. Rollout restart the Management Group namespaces:
    kubectl rollout restart -n <ocnadd-ns> deployment
    For example, in the management namespace ocnadd-mgmt:
    kubectl rollout restart -n ocnadd-mgmt deployment
  2. Rollout restart deployments in all Worker Group namespaces:
    kubectl rollout restart -n <ocnadd-ns> deployment
    For example, in the management namespace ocnadd-wg1:
    kubectl rollout restart -n ocnadd-wg1 deployment
  3. Rollout restart stateful sets in all Worker Group namespaces:
    kubectl rollout restart -n <ocnadd-ns> statefulset
    For example, in the management namespace ocnadd-wg1:
    kubectl rollout restart -n ocnadd-wg1 statefulset