Skip to content

Perform a Minor Migration


Key ideas:

  • Responsibility: The owner of the platform is responsible for migrate the platform.
  • Downtime: During minor migration, there is no specific downtime. Only restart channels or tasks.
  • Impact on the service: The monitoring component has to be restarted, so you have to discard supervision monitoring during the migration.
  • Rollback: Very easy, patch two environment variable and redeploy. Must be taken 10 min.



1) Check the version of the platform:

# Go to an operator device and type
# You must have this kind of output:
 PunchPlatform package:

2) Check if patch exists on the platform:

It\'s a key point to check! Go to an operator servers and check the existence of the directory.

Usually, it is located at /data/opt/punch-operator-[dataanalytics-]X.Y.Z

If patch exists, check the release notes of the version and verify the bug has been fixed in the new release. If a doubt subsists, please contact

3) Check the platform status

  • All must be green in Punchplatform Monitoring dashboard
  • Nagios (or other monitoring components) must be all OK (especially with the System, storage, memory, CPU).

At this point, you must have a strong picture of the platform (version, patch, system status). If you have question or doubt, please contact the N3 support).


1) Update environment

On the deployment device (usually Ansible), update your environment variable.


comment the old one, to rollback easily if necessary

For instance:

$ vim ~/.bashrc
 export PUNCHPLATFORM_LOG_DIR=/data2/deployer/logs
 export PUNCHPLATFORM_CONF_DIR=/data2/deployer/live-demo-pp-conf
 #export PATH=/data2/deployer/punchplatform-deployer-<CURRENT_VERSION>/bin:/home/loic/bin:/home/loic/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
 export PATH=/data2/deployer/punchplatform-deployer-<NEW_VERSION>/bin:/home/loic/bin:/home/loic/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

Then, refresh your variable:

ssh (again)

2) Create a git tag before migration

Always on the deployment device, go to $PUNCHPLATFORM_CONF_DIR and tag the version

$ git pull
$ git tag -a v<CURRENT_VERSION> -m "before migrate to <NEW_VERSION>"
$ git push --tags

3) Update configuration

Get the version of the operator-environment :

# go to archives directory in deployer
$ ls |grep operator-environment
# get the operator-environment version

Then, update the punchplatform-deployment.settings with the previous versions found:

"punchplatform_operator_environment_version" : "punch-operator-[dataanalytics-]<version>",

Then, check the breaking changes in documentation (if exists) to update configuration.

4) Generate the deployment configuration

The deployer has the capacity to generate inventories and variables use by ansible to deploy punchplatform components. Testing the generation of these files has no impact of the running platform : it's only on local.

$ --generate-inventory

If errors, please check the and punchplatform-deployment.settings configuration, THEN contact the N3 support.

5) Commit you first changes

Push the new configuration - no impact on the running platform !

$ git push

6) Notice of intervention communication

The next step has an impact on the running platform. It's crucial to contact / communicate to all stakeholders before continue !


1) Punchplatform Operator deployment

At this step, no running component will be impacted ! Only monitoring component will restart. You still have the capacity to stop/start/reload component with the current version of the platform. In other words: the impact of this deployment is low.

$ --deploy -Kk -t operator -l punchplatform_operator_servers

2) Test the new operator environment version

At this step, we are going to test the new version of the operator environment.

# ssh (again)
channelctl stop --channel <channel>
channelctl start --channel <channel>

After these commands, check:

  • first: the behaviour of the channel: Rate, Fails, Content of the logs in Elasticsearch, in the SIEM etc...
  • second: check the monitoring status.


If errors appears, no panic! Rollback your environment with the old deployer (rollback deployment environment variable and redeploy operators )


1) Tag the end of migration

From the operator device:

$ git pull
$ git tag -a v<NEW_VERSION> -m "end of migration to <NEW_VERSION>"
$ git push --tags

2) Notice of intervention communication

Announce the end of the migration to all stakeholders

3) Check again the behaviour of the platform ;)