Known Issues (3.0)

Owned by Jenni Wallin
Last updated: Dec 15, 2023
6 min read

In Usage Engine 3.0, there are the following known issues:

EC Pod Fails to Start With Custom Service Account

If you are setting a custom service account via the global.serviceAccountName helm value, then the EC pods will fail to start and end up in a CrashLoopBackoff status.

In the EC pod log there will be information saying that the default service account is forbidden from patching pods/status resources.

This issue will be fixed in the next minor release. 

In the meantime, the workaround is to manually bind the appropriate access rule to the default service account:

Workaround Example
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: ec-workaround-role
rules:
  - apiGroups: [""]
    resources: ["pods/status"]
    verbs: ["get", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ec-workaround-rolebinding
subjects:
  - kind: ServiceAccount
    name: default
roleRef:
  kind: Role
  name: ec-workaround-role
  apiGroup: rbac.authorization.k8s.io

Encrypted Workflows Cannot be Viewed in MZOnline

In MZOnline, any encrypted workflows cannot be viewed.

Documentation for System Properties Not Up-to-Date

The descriptions of properties in the Administrator Guide are not up-to-date, so ensure to check what is available in your yaml.values file. Documentation will be updated for the next minor release.

GET Method issue when using HTTP/2 Client with OpenAPI profile

When using the OpenAPI profile, you might encounter an issue where using the HTTP/2 Client to send a GET method to retrieve an API response. When the agent receives the response, you will encounter a Null Pointer Exception.

mzcli Commands Do Not Provide Return Codes

If you are using scripted solutions requiring return codes, you must use the mzsh commands, since the mzcli commands do not provide return codes.

Pico Details Not Entirely Correct

When looking at pico details, either in the Web Interface or in the Pico Viewer, the details may not be entirely correct regarding number of CPUs and IP address.

Removing Dynamic Fields May Cause Problems in the Web Interface

When having changed fields in the Workflow Properties from being dynamic per workflow to being final, you may have problems running the workflow in the Web Interface.

OpenAPI Validation Error for Type enum

There is a bug when performing OpenAPI validation for parameters of the enum type. The bug is based on: https://bitbucket.org/atlassian/swagger-request-validator/issues/161/mockmvc-openapi-30-type-of-enum-parameter

The error is recorded as:

Error(s) during request validation:

Unable to parse JSON - Unrecognized token'xxx': was expecting (JSON String, Number, Array, Object or token 'null', 'true' or 'false')

This occurs when you send a request to an NRF server that is configured using our HTTP2 Server agent with OpenAPI validation enabled. You will be meet with a Bad Request error (Error 400) and the validation fails. There was an issue with the specifications for the type enum within the 'anyOf' section as seen from the example below.

Example: NFType found in TS29510_Nnrf_NFManagement.yaml

    NFType:
      description: NF types known to NRF
      anyOf:
        - type: string
          enum:
            - NRF
            - UDM
            - AMF
            - SMF
            - AUSF
            - NEF
            - PCF
            - SMSF
            - NSSF
            - UDR
            - LMF
            - GMLC
            - 5G_EIR
            - SEPP
            - UPF
            - N3IWF
            - AF
            - UDSF
            - BSF
            - CHF
            - NWDAF
            - PCSCF
            - CBCF
            - HSS
            - UCMF
            - SOR_AF
            - SPAF
            - MME
            - SCSAS
            - SCEF
            - SCP
        - type: string


A workaround would be to add the 'type: string' parameter on the same level as the 'anyOf'.

AWS Terraform Template does not Support M1 Mac with darwin_arm64 Architecture

The setup files for AWS installation does not contain a provider that supports the new M1 Mac darwin_arm64 architecture.

The error is recorded as:

➜ terraform terraform init
Initializing the backend...

Initializing provider plugins...

Finding hashicorp/aws versions matching "~> 2.0"...
â•·
│ Warning: Version constraints inside provider configuration blocks are deprecated
│
│ on provider.tf line 5, in provider "aws":
│ 5: version = "~> 2.0"
│
│ Terraform 0.13 and earlier allowed provider version constraints inside the provider configuration block, but that is now deprecated and will be removed in a future version of
│ Terraform. To silence this warning, move the provider version constraint into the required_providers block.
╵
â•·
│ Error: Incompatible provider version
│
│ Provider registry.terraform.io/hashicorp/aws v2.70.1 does not have a package available for your current platform, darwin_arm64.
│
│ Provider releases are separate from Terraform CLI releases, so not all providers are available for all platforms. Other versions of this provider may have different platforms
│ supported.

Importing Old Data Veracity Collection Agent Workflow Configurations Returned Validation Errors

If you have an old Data Veracity Collection Agent Workflow configuration from version 8.x, it is possible that validation errors about invalid Analysis Agents may occur.

Example error during import:

The following agents returned validation errors.
Analysis_1 is invalid.
The UDR type DataVeracityUDR (DataVeracity) doesn't exist

Example error when viewing the invalid workflow Analysis Agent configuration:

Error: Failed to set UDR Types
 
Message: Unable to create UDR type description from DataVeracityUDR (DataVeracity).

To resolve this, you will need to re-add the Data Veracity UDR for Analysis Agent input UDR Types or use the Set To Input button if applicable. After adding the appropriate Analysis UDR Types, save the workflow configuration.

5G Profile Not Backward Compatible

Users may encounter validation errors during data import from version 8.x. This results in missing configurations in the 5G Profile and workflow, and users are required to reconfigure the 5G related settings.

Missing <Agent> - 5G <Field> Parameters in Workflow Table and Workflow Instance Table

The HTTP2_Server_1 - 5G - 5G Profile, HTTP2_Server_1 - 5G - Primary NRF Address, and HTTP2_Server_1 - 5G - Secondary NRF Addresses parameters in version 8.3.2.X are missing from the Workflow Table and workflow instance table when upgrading from version 8.3.2.1 onwards to Usage Engine 3.0.

The '<agent> - 5G - <field>' parameters in version 8.3.2.X

This is because the three parameters are classified under a different sub-category, the '5G Support' as HTTP2_Server_1 - 5G Support - 5G Profile, HTTP2_Server_1 - 5G Support - NRF Address, and HTTP2_Server_1 - 5G Support - Secondary NRF Address. 

The '<agent> - 5G Support - <field>' parameters in Usage Engine 3.0

If the existing workflow contains these parameters from the older version, users are required to configure them under the new '5G Support' sub-category.