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:
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'.
The property for limiting password changes needs the property "reset.enabled" to be set
Workaround
Settings for the platform, values.yaml:
systemProperties: - mz.security.user.control.enabled=true - mz.security.user.password.reset.enabled=true - mz.user.account.change.password.limit=true
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:
|
Example error when viewing the invalid workflow Analysis Agent configuration:
|
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.
Add Comment