Ericsson ENM migration: interface checks and recovery planning

Operational context and boundary scope

This note applies to a transition from a legacy OSS-RC installation to Ericsson Network Manager (ENM) and to a major ENM release change on an installed system, on physical, virtual or cloud-native ENM. The installed release, the deployment model and the vendor documentation for that combination decide the procedure. This note decides what you verify before you trust it.

The change fails at the handoffs. The network management team, T1 in our layer model, owns the manager, its node integrations and the FM, CM and PM northbound interfaces. Where ENM runs virtualized or cloud-native, the platform team, T2, owns the hypervisor or cluster, its storage, its time source and its admission rules. The delivery pipeline owns the cutover scripts, and the NOC dashboards and reporting jobs that consume alarms and performance files sit in T3. Each team tests its own layer; nobody tests the seam.

Every check in this note runs inside the read-only diagnostic scope we onboard with (STC-ONB-01): an ENM role limited to cmedit get and read-only AMOS inspection, with set, create, delete and action not granted; cluster-reader on a cloud-native ENM platform; Argo CD role:readonly and GitLab Reporter on the repository that holds the cutover scripts. The write steps of the window belong to the operator’s own change role and to the vendor procedure. Keeping the two scopes apart lets the pre-flight run as often as you like without becoming a change of its own.

• Ericsson Network Manager product overview

Pre-window readiness and dependency matrix

Run the matrix on representative nodes, one per node model and release in scope, in the test environment first and again against production during the pre-window checks. Every row needs an evidence reference attached to the change record before the window opens. A row without evidence is a failed row, and a failed row stops the first wave.

• Ericsson Network Manager product overview

Reference implementation artifact

The script collects the node-side and platform-side evidence for ENM-02 through ENM-05 from an ENM scripting client. Every command reads. The guard at the top refuses to run if a write verb is ever pasted into the file, which keeps the script inside the STC-ONB-01 scope. The report and its digest are the baseline for the post-wave comparison.

Command syntax is illustrative for the ENM command-line interface, and alarm commands differ between releases. Run it against the test environment and correct it before relying on it, replace the placeholders, and keep the report with the change record rather than in a home directory.

#!/usr/bin/env bash
# enm-preflight.sh -- read-only evidence collection before an ENM change window.
# Scope matches the STC-ONB-01 diagnostic role: cmedit get and read-only AMOS inspection only.
# Nothing below issues set, create, delete or action against a node or the manager.
set -euo pipefail

ENM_HOST="enm.example.invalid"
# One representative node per node model and release in scope.
NODES="REPLACE_WITH_NODE_A REPLACE_WITH_NODE_B"
CHANGE_ID="REPLACE_WITH_CHANGE_ID"
REPORT="enm-preflight-${CHANGE_ID}-$(date -u +%Y%m%dT%H%M%SZ).txt"

# Guard: refuse to run if a write verb is ever pasted into this file.
if grep -nE '^[^#]*\bcmedit (set|create|delete|action)\b' "${BASH_SOURCE[0]}"; then
  echo "write verb found in a read-only script; stop" >&2
  exit 1
fi

{
  echo "change: ${CHANGE_ID}  manager: ${ENM_HOST}  collected: $(date -u +%FT%TZ)"
  echo "operator: $(whoami)  scope: read-only (STC-ONB-01)"

  # ENM-05, platform seam: certificate validity and clock state as seen from this client.
  echo "== manager certificate"
  openssl s_client -connect "${ENM_HOST}:443" -servername "${ENM_HOST}" </dev/null 2>/dev/null \
    | openssl x509 -noout -subject -enddate
  echo "== clock"
  chronyc tracking 2>/dev/null | grep -E 'System time|Leap status' || timedatectl show -p NTPSynchronized

  for node in ${NODES}; do
    echo "== ${node}"
    # ENM-02: sync state and model identity. An unsynchronized node proves nothing about CM.
    cmedit get "${node}" CmFunction.syncStatus
    cmedit get "${node}" 'NetworkElement.(neType,ossModelIdentity,release)'
    # ENM-03 and ENM-04: supervision must be on before the FM and PM rows mean anything.
    cmedit get "${node}" FmAlarmSupervision.active
    cmedit get "${node}" PmFunction.pmEnabled
    # ENM-03 baseline: the open alarm list the post-wave comparison starts from.
    # Alarm command syntax differs between ENM releases; confirm it on the test client first.
    alarm get -n "${node}"
  done
} > "${REPORT}"

sha256sum "${REPORT}"
echo "evidence written to ${REPORT}; attach the file and its digest to change ${CHANGE_ID}"

Execution sequence, blast radius and recovery

Sequence the window by waves of nodes, not by manager steps. Before the first wave, ENM-01 to ENM-07 are green with evidence digests and the pre-flight report has been taken twice, the day before and an hour before, so a difference between the two is itself a finding. A wave is a node group small enough that losing its supervision for the length of the wave stays inside the visibility threshold the NOC agreed to; that threshold sets the blast radius, not the number of nodes an engineer can type.

After each wave, repeat ENM-02 and ENM-03 on the nodes it touched, and ENM-04 at the next reporting period, before the next wave starts. Any stop trigger stops the sequence at the wave boundary. The plan says which triggers mean hold and which mean roll back.

Control-plane rollback is the manager itself: its application configuration, its databases, the node integration records and, for cloud-native ENM, the Kubernetes resources that run it. The vendor backup and restore procedure covers this state. On a cloud-native platform the Git revision that describes the platform namespaces reverts through the pipeline and an approved Argo CD sync; the manager’s own data is not in Git. Components that need more than restricted-v2 run under vendor-supported SCCs with a reviewed exception, and that exception is part of the state you restore.

Persistent alarm and performance data is a different asset. Historical alarms, PM files collected after the backup point and the records northbound consumers derived from them are not returned by restoring the manager. Decide before the window whether that gap is acceptable, how consumers re-collect it and who signs off the loss. Node state is a third boundary: configuration pushed to nodes during a wave persists after a manager restore, and reversing it is a CM change with its own approval, so the list of changes the window may make is also the reversal list.

Write the recovery authority down: who can call the rollback, on which triggers, how long the restore takes, measured in the test environment, and who tells the NOC. A recovery procedure that has not been exercised on the installed release is an assumption, not a plan.

• Ericsson Network Manager product overview
• OpenShift Container Platform 4.20: security context constraints

Educational disclaimer

This is an engineering reference, not a report of a customer migration and not a vendor procedure. Command names, managed-object attributes and deployment details illustrate the checks and differ between ENM releases and deployment models. Validate every command, compatibility statement and recovery step against the Ericsson documentation for your installed release and your support entitlement, and rehearse it in a test environment before a production change window.