Software Upgrade

Sipwise C5 can be upgraded to mr11.4.1 from previous LTS release, or any non-LTS release since the previous LTS-release.

The mr11.4.1 maintenance release uses the new upgrade approach commonly known as 'A/B Upgrade'

ngcp-upgrade requires a special partitioning schema of disk subsystem. The server has 3 separate partitions:

ngcp-data - it stores data files, like databases files, logs, etc.

ngcp-root and ngcp-fallback - they are equal size and contain the software, OS files and NGCP packages. One of them is the current root '/' partition, the another one is mounted as /ngcp-fallback directory.

See more details in The default disk partitions

During the upgrade the second partition is formatted and the target version is installed into it. After the reboot the system will be started from this partition and previous one becomes the /ngcp-fallback directory.

Please, pay particular attention that this partitioning schema is mandatory and if your system doesn’t have it - create it beforehand. You can reinstall node from the peer and re-join the cluster. WARNING: This is the only supported upgrade schema. The old, in-place upgrade is not supported and technically not possible.

Release Notes

Starting from Sipwise C5 version mr11.3.1 the Soundset inheritance feature has been added. Every Sound_Set can have a parent Sound_Set: if the parent is configured, all the announcements not defined in the current Sound_Set will be inherited from the parent, if any.

Additionally the Contract_Sound_Set has been extended to contain all the announcements available in the standard Sound_Set. In case both of the sound set types are assigned to a subscriber, the Contract_Sound_Set takes precedence. Sipwise C5 systems without the CloudPBX module enabled or where Contract_Sound_Set are not assigned to Subscribers/Customers will not be affected. This change could instead have an impact on all the Subscribers/Customers with Contract_Sound_Set assigned. This is because right after the upgrade Contract_Sound_Set contain many handles without an associated announcement (for example all the Early Media announcements). In this case Sipwise C5 will not play any message back to the caller.

To solve this, a new script called 'ngcp-upgrade-contract-sound-sets' has been created. The script automatically runs through all Contract_Sound_Set assigned to subscribers and if those subscribers all use the same Sound_Set, the Sound_Set is set as a parent of the respective Contract_Sound_Set. For subscribers using a different Sound_Set, a copy of the Contract_Sound_Set is created as 'Contract_Sound_Set copy #1' for each discrepant Sound_Set (the following copies of the same Contract_Sound_Set are created as '…​ copy #2' and so on). The script can be called anytime after the upgrade to version mr11.3.1. If no parameter is specified, the script will simply print in the standard output the list of operations it is going to perform, without actually executing them. When all the reported changes has been acknowledged by the system administrator, the script has to be run again with '--apply' parameter. In this case the operations are committed to the database. Further invocations of the script will not have any effect on the system.

If you don’t want any automated changes to the provisioned Contract_Sound_Set, you can manually apply one of the following solutions through the web or api interfaces:

  1. Extend all the used Contract_Sound_Set by uploading the missing sound files. This solution should be avoided because it will increase the number of uploaded announcement in the database with a consistent grow of the used disk space.

  2. For all the used Contract_Sound_Set set the Sound_Set as a parent. This step enables the Contract_Sound_Set to inherit from the parent all the missing announcements. In case if more than one subscriber uses the same Contract_Sound_Set but a different Sound_Set, then it will be necessary to clone the Contract_Sound_Set, in order to have one for each such Subscriber. This solution is the preferred one for clients who decide to manually perform the necessary changes.

Please find the complete release notes and changelog of Sipwise C5 version mr11.4.1 on our WEB site.

Overview

The Sipwise C5 software upgrade procedure to mr11.4.1 will perform several fundamental tasks, and it’s split into 2 stages:

First stage:

  • do pre-upgrade checks

  • format fallback partition

  • install Debian to fallback partition

  • install NGCP packages to fallback partition

  • copy current configuration to fallback partition

  • upgrade the NGCP configuration schema in fallback partition

  • update grub configuration so after reboot the current fallback partition becomes the active one

Second stage:

  • reboot to new partition. This steps needs to be taken care manually during maintenance window

  • upgrade the NGCP database schema

The 1st stage is safe to run outside the maintenance window - it changes nothing on currently running system, only prepares the fallback partition.

Also it can be done in parallel on all the nodes.

It still can affect the system in term of CPU, network and disk load, to download, unpack and install the packages.
Grub configuration is changed so in case of any reboot (expected or not) system will be booted to mr11.4.1 partition. It won’t affect the installation though as no NGCP services are run there. So if it was unintentionally you can reboot it back to previous partition via Rollback procedure.

The 2nd stage should be run during maintenance window with enabled maintenance mode in configuration.

Please make sure to have remote access to the system via out-of-band management (like IPMI, iLO, IMM, iDRAC, KVM, etc)

Sipwise C5 CARRIER is a PRO-style system that has "A" and "B" sets of nodes with specific roles. The number of nodes can differ between installations and must be clarified before the upgrade at the planning stage.

The software upgrade is usually performed by Sipwise engineers according to the following steps:

  • create the software upgrade plan

  • execute pre-upgrade steps: patchtt, customtt, backups, checks

  • perform the first stage of upgrade on all the nodes

  • make all "B" nodes (on CARRIER) or the sp2 node (on PRO) active

  • ensure that all "A" nodes (on CARRIER) or the sp1 node (on PRO) are standby

  • enable Maintenance Mode

  • perform the second stage of upgrade on all "A" nodes (on CARRIER) or the sp1 node (on PRO)

  • schedule and make services switchover to all "A" nodes (on CARRIER) or the sp1 node (on PRO)

  • ensure that "A" nodes (on CARRIER) or the sp1 node (on PRO) perform well (otherwise, perform a switch back)

  • perform the second stage of upgrade on all "B" nodes (on CARRIER) or the sp2 node (on PRO)

  • perform the system post-upgrade testing and cleanup

The only allowed software upgrade path is the one described above. The nodes sp1/s2 (or a/b) MUST be used as described in this document. All the other theoretically possible upgrade scenarios can lead to unpredictable results.

Planning a software upgrade

Confirm the following information:

  • which system should be upgraded (LAB/LIVE, country, etc.)

  • the date and time schedule for each of the steps above (keeping the time zone in mind)

  • a confirmed timeframe for the upgrade operation (allowed switchover timeframe)

  • the basic functionality test (BFT) to be executed before the start of the software upgrade and after the switchovers to ensure that the new release does not show critical issues (the BFT scenario should be prepared by the customer engineers)

  • actions to be taken if the software upgrade operation cannot be completed within the defined maintenance window

  • contact persons and ways of communication in case of emergency

  • ensure that the customer and/or Sipwise engineers have access to the virtual consoles of the servers: KVM, iDRAC, AMM

Pre-upgrade checks

It is recommended to execute the preparatory steps in this chapter a few days before the actual software upgrade. They do not cause a service downtime, so it is safe to execute them during peak hours.

Log into the NGCP standby management node

This should be web01a on CARRIER and sp1 on PRO.

Use the static server IP address so you can switch between the nodes.

Run the terminal multiplexer under the sipwise user (to reuse the Sipwise .screenrc settings that are convenient for working in multiple windows):

screen -S my_screen_name_for_ngcp_upgrade

Become root inside your screen session:

sudo -s

Check the overall system status

Check the overall system status:

ngcp-status --all

Make sure that the cluster health status is OK: Check the nodes in parallel, using the 'ngcp-cluster-status' command, which will perform various checks in sequence to ensure the various nodes have a consistent and healthy sate.

Check access to license server and license validity

Check from within the system (better from all nodes, for extra safety) that the license server is accessible from the network point of view, and that these commands do not end with timeouts or HTTP errors:

ping -c 3 -w 5 license.sipwise.com

curl --head https://license.sipwise.com/

Also ensure that:

  • /proc/ngcp/check contains the string "ok" (if not, check logs)

  • and that there are no errors or important warnings in /ngcp-data/logs/licensed.log

Evaluate and update custom modifications

For the below steps, investigate and make sure you understand why the custom modifications were introduced and if they are still required after the software upgrade. If the custom modifications are not required anymore, remove them (e.g. if a bug was fixed in the target release and the existing patch becomes irrelevant).

Create tickets to Sipwise developers to make relevant custom modifications part of the product in future releases. This allows you to get rid of the customtt files one day.

If you directly change the working configuration (e.g. add custom templates or change the existing ones) for some reason, then the system must be thoroughly tested after these changes have been applied. Continue with the software upgrade preparation only if the results of the tests are acceptable.

Find the local changes to the template files:

ngcp-customtt-diff-helper

The script will also ask you if you would like to download the templates for your target release. To download the new templates separately, execute:

ngcp-customtt-diff-helper -d

In the tmp folder provided by the script, you can review the patchtt files or merge the current customtt with the new tt2 templates, creating the new customtt.tt2 files. Once you do this, archive the new patchtt/customtt files to reapply your custom modifications after the software upgrade:

ngcp-customtt-diff-helper -t

Find all available script options with the "-h" parameter.

Check system integrity

Log into all the servers.

Open separate windows for all the servers inside your "screen" session. (Press Ctrl+a + c to open a new window, Ctrl+a + a or Ctrl+a + [0-9] to change the window. Ctrl+a + " shows the list of all your windows. Use Ctrl+a + A to change the window names to corresponding hosts).

Changes made directly in tt2 templates will be lost after the software upgrade. Only custom changes made in customtt.tt2 or added by patchtt.tt2 files will be kept. Hence, check the system for locally modified tt2 files on all nodes:

ngcp-status --integrity

Check the configuration framework status

Check the configuration framework status on all nodes. All checks must show the "OK" result and there must be no actions required:

ngcpcfg status

On a CARRIER, check the replication on both central DB servers and on ports 3306 and 3308 of all the proxy servers. Ensure that all the proxy nodes replicate the read-only DB (127.0.0.1:3308) from the db01a node. Otherwise, discuss a special plan to address your particular configuration.

On a PRO, check the replication on both nodes.

The result must always show:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0

Test the cluster failover to see if everything works fine as well on "B" nodes (on a CARRIER) or the second node (on a PRO). On all the standby nodes execute:

ngcp-make-active

Create two test subscribers or use the credentials for existing ones. Register subscribers with the platform and perform a test call to ensure that call routing and media flow are working fine.

Run "apt-get update" on all nodes and ensure that you do not have any warnings and errors in the output.

If the installation uses locally specified mirrors, then the mirrors must be switched to the Sipwise APT repositories (at least for the software upgrade). Otherwise, the public Debian mirrors may not provide packages for old Releases anymore or at least provide outdated ones!

Check access to deb.sipwise.com

Ensure that both management nodes have access to deb.sipwise.com by executing the following commands on a management node:

ngcp-approx-cache --check --node sp1

ngcp-approx-cache --check --node sp2

The checks must show only 200 OK results. If you see cannot connect!, Received 404 or any other error, check these possible causes:

  • A node does not have a connection to deb.sipwise.com

  • The deb.sipwise.com whitelist does not have the node’s public IP (IPv6) address.

Check PPA(s)

Check if there are PPA(s) in the configuration:

ngcpcfg get bootenv.ppa.size

Check if there are PPA(s) added manually:

cat /etc/apt/sources.list.d/sipwise_ppa.list

If PPA(s) are listed then consult with OPS if a new version of the PPA is required for the new to be upgraded version.

Before starting the upgrade the old PPA(s) need to be removed. If a new PPA is required then this should be in place before starting the upgrade.

License check

The Sipwise C5 enforce software licensing restrictions in form of a regular comparison of the licensed services and capacities against the actual usage patterns of the platform. In case some functionalities are enabled but not licensed, an error in syslog will be reported and the impacted services will be automatically deactivated.

Before proceeding with the upgrade, please take some time to check that all the modules not licensed are actually disabled in config.yml file. To verify if they are enabled execute the following commands (versions before mr10.5):

ngcpcfg get sems.prepaid.enable
ngcpcfg get sems.sbc.xfer.enable
ngcpcfg get pbx.enable
ngcpcfg get pushd.enable
ngcpcfg get intercept.enable
ngcpcfg get voisniff.admin_panel
ngcpcfg get voisniff.daemon.li_x1x2x3.enable
ngcpcfg get voisniff.daemon.start
ngcpcfg get tpcc.enable
ngcpcfg get websocket.enable

To verify if they are enabled execute the following commands (all version including mr10.5 and later):

ngcpcfg get b2b.prepaid.enable
ngcpcfg get b2b.sbc.xfer.enable
ngcpcfg get pbx.enable
ngcpcfg get pushd.enable
ngcpcfg get intercept.enable
ngcpcfg get voisniff.admin_panel
ngcpcfg get voisniff.daemon.li_x1x2x3.enable
ngcpcfg get voisniff.daemon.start
ngcpcfg get tpcc.enable
ngcpcfg get websocket.enable

If the output of one of the commands is 'yes' but the module is not licensed, you have to deactivate it. For example, in case of pre-paid billing module execute (versions before mr10.5):

ngcpcfg set /etc/ngcp-config/config.yml sems.prepaid.enable=no
ngcpcfg apply 'Disable prepaid module'
ngcpcfg push all

For example, in case of pre-paid billing module execute (all version including mr10.5 and later):

ngcpcfg set /etc/ngcp-config/config.yml b2b.prepaid.enable=no
ngcpcfg apply 'Disable prepaid module'
ngcpcfg push all
Please, pay particular attention to pre-paid billing module because it is enabled by default.

Pre-upgrade steps

Download new package metadata into the approx cache (on the standby node only)

Customers with far-sighted software upgrade policies usually have pre-production installations to test the services in their environment before upgrading the production platform. In this case, the approx cache should be updated on both platforms simultaneously to synchronize the package versions between them, hence consider carefully before executing this step.

To download the latest packages metadata into the approx cache, execute the following command on the standby management node. This action ensures that all nodes within the platform have identical packages after the software upgrade:

ngcp-approx-cache --update --skip-all-repos --extra-ngcp-release mr11.4.1

Run the following command node to install the package responsible for upgrading Sipwise C5 to a newer release:

ngcp-prepare-upgrade mr11.4.1
Don’t worry, ngcp-upgrade-carrier does not exist, ngcp-upgrade-pro is used in Carrier too.

Run upgrade checks

There is a list of checks before the actual upgrade so it’s wise to run them beforehand to detect and fix all the issues.

ngcp-upgrade-pre-checks mr11.4.1
If there is an error during the upgrade, the ngcp-upgrade script will request you to solve it. Once you’ve fixed the problem, execute ngcp-upgrade again and it will continue from the previous step.

The upgrade script will ask you to confirm that you want to start. Read the given information carefully, and if you agree, proceed with y.

The upgrade process will take several minutes, depending on your network connection and server performance. After everything has been updated successfully, it will finally ask you to reboot your system. Confirm to let the system reboot (it will boot with an updated kernel).

ngcp-upgrade options

The following options in ngcp-upgrade can be specially useful in some instances of upgrade:

  • --step-by-step: confirm before proceeding to next step. With this option the upgrade operation is performed confirming every step before execution, with the possibility to instruct to continue without confirming further steps until the end (if confirmation is only needed for some steps at the beginning).

  • --pause-before-step STEP_NAME: pause execution before step, given by the name of the script (e.g. "backup_mysql_db"). This option can be useful in several scenarios, for example:

    • to help to debug problems or work around known problems during upgrades. In this case the operator can pause at a given step known to be problematic or right before a problematic set, perform some manual checks or changes, then continue the upgrade until another step (with confirmation like with the recent option --step-by-step), or continue without stop until the end

    • another use might be to help to speed up upgrades when it involves several nodes: they can all proceed in parallel when it’s known to be safe to do so; then perform some parts in lock-step (some nodes waiting until others finish with some stage); then continue in parallel until the end

  • --skip-db-backup: This will speed-up the process in cases where it’s deemed unnecessary, and this is very likely in the upgrade of nodes other than the first.

Upgrading Sipwise C5 CARRIER

Log in to all nodes and execute the checks from Pre-upgrade checks again. This will ensure that nothing was broken since the preparation steps were finished. Also, execute ngcpcfg show and ngcpcfg status to check the latest configuration changes.

Perform the BFT test.

The custom modification handling (optional)

During the execution of ngcp-upgrade on the 1st node in step place_customtt_files, you will be asked to place customtt/patchtt files for the new system to /ngcp-fallback/etc/ngcp-config.

When one node is fully upgraded, you won’t be asked about customtt/patchtt files in the upgrade of the following nodes.

If, after upgrading all "A" nodes and promoting them to active ones, you found that you need to change something in customtt/patchtt files - do it, execute ngcpcfg apply, and push commit to shared storage. Do not push it to all the nodes but upgraded ones only (all "A" nodes).

First stage of upgrade

You can run 1st stage outside the maintenance window. Also you can run this stage in parallel on all the nodes ("A" and "B" ones).

To do this run the upgrade script on the nodes as root:

ngcp-upgrade --target mr11.4.1

There is "stop" step in upgrade scenario, ngc-upgrade stops there. At this time the new system in fallback partition is ready.

Enable Maintenance Mode

The maintenance mode of Sipwise C5 will disable some background services (for instance: ngcp-mediator) during the software upgrade. It thus prevents the system from getting into an inconsistent state while the upgrade is being performed. You can activate maintenance mode by applying a simple configuration change as described later.

  • Pull pending configuration (if any):

ngcpcfg pull

  • Enable maintenance mode:

If you upgrade from version mr11.1.1 or lower use:

ngcpcfg set /etc/ngcp-config/config.yml "general.maintenance=yes"

Otherwise use:

ngcpcfg set /etc/ngcp-config/maintenance.yml "general.maintenance=yes"

  • Apply configuration changes by executing:

ngcpcfg apply 'Enabling maintenance mode before the upgrade to mr11.4.1'
ngcpcfg push all

Second stage of upgrade

Upgrading the standby management node "A" (web01a/db01a)*

Sometimes the DB and MGMT roles are assigned to the same host. This is OK.
Do NOT run the second stage on management and db node in parallel!

Before reboot switch boot record, run as root:

/usr/share/ngcp-upgrade/ngcp-switch-root-partition

Reboot the management node and run as root:

ngcp-upgrade --target mr11.4.1

Upgrading the standby database node "A" (db*a)

If the DB and MGMT roles are assigned to the same host, then skip this step as you have already upgraded the standby MGMT node "A" above.

Before reboot switch boot record, run as root:

/usr/share/ngcp-upgrade/ngcp-switch-root-partition

Reboot the database node and run as root:

ngcp-upgrade --target mr11.4.1
It is important to upgrade db01a node before upgrading any proxy nodes. Otherwise, the "local" MySQL (127.0.0.1:3308) on proxy nodes may become out of sync in case the new release has _not_replicated.up DB statements.

Upgrading other standby nodes "A" (lb*a/prx*a)

This part of the upgrade can be done in parallel on other "A" nodes.

Before reboot switch boot record, run as root:

/usr/share/ngcp-upgrade/ngcp-switch-root-partition

Reboot the node and run as root:

ngcp-upgrade --target mr11.4.1

Useful options in ngcp-upgrade

The following options in ngcp-upgrade can be useful for this phase of upgrades, because it is very likely that the backup was already performed:

  • --skip-db-backup: This will speed-up the process in cases where it’s deemed unnecessary.

See a more detailed description of the options in: ngcp-upgrade options

Promote ALL standby nodes "A" to active.

Ensure that all standby nodes "A" are: * upgraded to the new release (check /etc/ngcp_version or use 'ngcp-cluster-status')

Prior to the promotion, the DB has to be updated with information from the new configuration. This should be done as close as possible to the activation of the upgraded nodes, to minimize the changes to the active service with the old release.

Execute on one of the standby nodes as root, for example on db01a:

MYSQL_VALUES_UPDATE_BEFORE_SWITCHOVER=true /etc/ngcp-config/templates/etc/ngcp-provisioning-tools/mysql_values.cfg.services

On all "A" nodes run:

ngcp-make-active

Ensure that the "A" nodes became active, by executing the 'ngcp-status' and 'ngcp-cluster-status' commands described above.

Ensure that ALL "B" nodes are standby now!

Upgrading ALL standby nodes "B" (web*b/db*b/lb*b/prx*b)

You can upgrade all standby "B" nodes simultaneously (including the ones with the mgmt and db roles).

Before reboot switch boot record, run as root:

/usr/share/ngcp-upgrade/ngcp-switch-root-partition

Reboot the node and run as root:

ngcp-upgrade --target mr11.4.1

Useful options in ngcp-upgrade

The following options in ngcp-upgrade can be useful for this phase of upgrades:

  • --step-by-step: confirm before proceeding to next step.

  • --pause-before-step STEP_NAME: pause execution before step, given by the name of the script (e.g. "backup_mysql_db").

See a more detailed description of the options in: ngcp-upgrade options

Upgrading Sipwise C5 PRO

Make sure you are prepared to spend about two hours upgrading the system. Note that a short service downtime is possible during the services switchover to the upgraded node.

Start with the software upgrade on the standby sp1 node. Then, switch the services over to the upgraded node and upgrade the other (now standby) sp2 node, as described in the steps below.

The custom modification handling (optional)

During the execution of ngcp-upgrade on the 1st node in step place_customtt_files, you will be asked to place customtt/patchtt files for the new system to /ngcp-fallback/etc/ngcp-config.

When one node is fully upgraded, you won’t be asked about customtt/patchtt files in the upgrade of the 2nd node.

If, after upgrading the 1st node and promoting it to active one, you found that you need to change something in customtt/patchtt files - do it, execute ngcpcfg apply, and push commit to shared storage. But do not push changes to 2nd node as it still running old system.

First stage of upgrade

You can run 1st stage outside the maintenance window. Also you can run this stage in parallel on all the nodes (sp1 and sp2).

To do this run the upgrade script on the nodes as root:

ngcp-upgrade --target mr11.4.1

There is "stop" step in upgrade scenario, ngcp-upgrade stops there. At this time the new system in fallback partition is ready.

Enable Maintenance Mode

The maintenance mode of Sipwise C5 will disable some background services (for instance: ngcp-mediator) during the software upgrade. It thus prevents the system from getting into an inconsistent state while the upgrade is being performed. You can activate maintenance mode by applying a simple configuration change as described later.

  • Pull pending configuration (if any):

ngcpcfg pull

  • Enable maintenance mode:

If you upgrade from version mr11.1.1 or lower use:

ngcpcfg set /etc/ngcp-config/config.yml "general.maintenance=yes"

Otherwise use:

ngcpcfg set /etc/ngcp-config/maintenance.yml "general.maintenance=yes"

  • Apply configuration changes by executing:

ngcpcfg apply 'Enabling maintenance mode before the upgrade to mr11.4.1'
ngcpcfg push all

Second stage of upgrade

Before reboot switch boot record, run as root:

/usr/share/ngcp-upgrade/ngcp-switch-root-partition

Reboot the standby node and run as root:

ngcp-upgrade --target mr11.4.1

Useful options in ngcp-upgrade

The following options in ngcp-upgrade can be useful for this phase of upgrades:

  • --step-by-step: confirm before proceeding to next step.

  • --pause-before-step STEP_NAME: pause execution before step, given by the name of the script (e.g. "backup_mysql_db").

See a more detailed description of the options in: ngcp-upgrade options

Promote the upgraded standby node to active

Prior to the promotion, the DB has to be updated with information from the new configuration. This should be done as close as possible to the activation of the upgraded node, to minimize the changes to the active service with the old release.

Execute on the current standby node as root:

MYSQL_VALUES_UPDATE_BEFORE_SWITCHOVER=true /etc/ngcp-config/templates/etc/ngcp-provisioning-tools/mysql_values.cfg.services
ngcp-make-active

Upgrade the second PRO node

Before reboot switch boot record, run as root:

/usr/share/ngcp-upgrade/ngcp-switch-root-partition

Reboot the new standby node and run as root:

ngcp-upgrade --target mr11.4.1

Useful options in ngcp-upgrade

The following options in ngcp-upgrade can be useful for this phase of upgrades, because it is very likely that the backup was already performed in the upgrade of the first node:

  • --skip-db-backup: This will speed-up the process in cases where it’s deemed unnecessary.

See a more detailed description of the options in: ngcp-upgrade options

Post-upgrade steps

Disabling maintenance mode

In order to disable the maintenance mode, do the following:

  • Pull outstanding ngcpcfg changes (if any):

ngcpcfg pull

  • Disable the maintenance mode:

ngcpcfg set /etc/ngcp-config/maintenance.yml "general.maintenance=no"

  • Apply the changes to configuration templates:

ngcpcfg apply 'Disable the maintenance mode after the upgrade to mr11.4.1'
ngcpcfg push all

Post-upgrade checks

When everything has finished successfully, check that replication is running. Check ngcp-status --all. Finally, do a basic functionality test. Check the web interface, register two test subscribers and perform a test call between them to ensure call routing works.

You can find a backup of some important configuration files of your existing installation under /ngcp-data/backup/ngcp-mr11.4.1-\* (where \* is a place holder for a timestamp) in case you need to roll back something at any time. A log file of the upgrade procedure is available at /ngcp-data/ngcp-upgrade/$FROM-mr11.4.1/logs/.

Applying the Latest Hotfixes

If your current release is already the latest or you prefer to be on the LTS release, we still suggest applying the latest hotfixes and critical bug fixes.

Execute all steps as described in Pre-upgrade checks. They include the system checks, customtt/patchtt preparation and others. It is important to execute all the steps from the above chapter.

On a CARRIER it is suggested to promote B-nodes to active and start the update with A-nodes.

Update the approx cache on the standby management node

The main goal of the following command is to download the new packages into the approx cache. So all the nodes in the cluster will get identical packages.

ngcp-approx-cache --auto --node localhost

Apply hotfixes on the standby management node

ngcp-update

If there are custom configuration templates

Merge/add the custom configuration templates if needed.

Apply the changes to configuration templates:

ngcpcfg apply 'apply customtt/patchtt after installing the latest packages'

Send the new templates to the shared storage and the other nodes.

ngcpcfg push --shared-only

Apply hotfixes on all other standby nodes (CARRIER-only)

ngcp-update

Promote the standby nodes to active

Execute on the standby nodes as root:

ngcp-make-active

Check in a minute that the nodes became active:

ngcp-check-active

Apply hotfixes on the second node

ngcp-update

Execute the final checks as described in the Post-upgrade checks section.