Page tree
Skip to end of metadata
Go to start of metadata

The following provides important information related to Usage Engine 2.2:

Simplified Delivery

The delivery of Usage Engine has now been simplified, and you no longer have to have helm s3 plugin installed, or a docker hub account.

Note!

Usage Engine helm and docker image repositories now reside in GitHub!

Helm charts and images are publicly available, hence no need for access credentials!

New helm chart URL : https://digitalroute-public.github.io/usage-engine-private-edition

See information for respective deployment options in Installation Instructions[hide]2.2[/hide].

Changes in OpsAPI

There has been changes been made to the OpsAPI. Instead of one single Openapi spec, there are now four different ones:

  • Workflow
  • Workflow group
  • Ext ref
  • Workflow state

Also, there are no html versions anymore. Just yaml.

Deprecated Ingress Controller

If you use the bundled ingress controller, i.e. setting helm value nginx.enabled=true, it should be noted that this is deprecated and will not work in Kubernetes v1.22 or later. Reason being that it relates to API:s that are removed in Kubernetes v1.22.

To enable an ingress nginx controller compatible with Kubernetes v1.19 - v1.22, please set nginx.enabled=false and instead ingress-nginx-v4=true.
This will enable ingress-nginx as a sub-chart. For documentation of ingress-nginx, please refer to: https://github.com/kubernetes/ingress-nginx

Upgrade from MediationZone 10.x

Note!

If you want to upgrade to  Usage Engine 2.2 from MediationZone 10.x, you need to be on a 10.6.x version.

In the upgrade scenario where the CRD already exist in the K8s cluster, a manual step prior to executing the helm upgrade command is required.

  • In order to carry out this step, the name and namespace of the existing MZ helm installation are required. This information can be obtained using the helm list command. In this example, we are going to assume that the existing MZ helm installation name is “my-mz” and its namespace is “my-mz-namespace”.

  • Once that information has been obtained, the following kubectl commands should be executed (note that you will need to replace “my-mz” and “my-mz-namespace” with whatever name and namespace you have in your environment):

    $ kubectl label crd ecdeployments.mz.digitalroute.com app.kubernetes.io/managed-by=Helm --overwrite
    $ kubectl annotate crd ecdeployments.mz.digitalroute.com meta.helm.sh/release-name=my-mz --overwrite
    $ kubectl annotate crd ecdeployments.mz.digitalroute.com meta.helm.sh/release-namespace=my-mz-namespace --overwrite
  • This will effectively mean that the CRD is now owned by the existing MZ helm installation. Now the helm upgrade command can be executed as per the normal procedure.

    Note!

    This manual step is only required once. Any subsequent upgrades can be executed without this manual step.

  • If the manual step outlined above is not carried out, an error message like this will typically be returned when executing the helm upgrade command:

    Error: rendered manifests contain a resource that already exists. 
    Unable to continue with install: CustomResourceDefinition "ecdeployments.mz.digitalroute.com" in namespace "" 
    exists and cannot be imported into the current release: invalid ownership metadata; 
    annotation validation error: key "meta.helm.sh/release-name" must equal "my-helm-release": 
    current value is "some-other-helm-release"; 
    annotation validation error: key "meta.helm.sh/release-namespace" must equal "my-namespace": 
    current value is "some-other-namespace"


  • No labels