Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This step is similar to Step 1 only that we will now add back the nodes we removed in step 1 and remove the running currently running nodes.

The nginx configuration should look like this:

...

Users having open sessions on "Weather" project version 1 should see no difference, but new users that access the project should be redirected to "Weather" project version 2.

4. Undeploying old versions

You can use two strategies to undeploy old versions

...

.

4.1 Undeploy during upgrades

Using the example above, version 0.0-v1 can be undeployed when upgrading 0.0-v2 to 0.0-v3. Using this strategy there are always two version deployed. In order to ensure users always use the latest version, make sure that the shortcut points to the latest versions and projects can only be started using shortcuts.

4.2 Undeploy after upgrade

4.2.1 Undeploy using the publisher

After a successful upgrade has been performed and sufficient time has passed so there are no more sessions using the old version, the old version can be unpublished. The cluster does not have to be restarted.

4.2.2 Undeploy export files

After a successful upgrade has been performed and sufficient time has passed so there are no more sessions using the old version, the old version can be deleted. The same process described in steps 1-3 can be used:

  • remove some of the nodes from the cluster
  • delete the old version from the nodes removed from the cluster
  • restart the nodes
  • add the nodes back to the cluster
  • repeat until the old version is deleted from all the nodes

 

Info

If the project exports are deployed on a shared folder, the old version will be deleted only once. The runtimes still have to be restarted in order to clear the application cache.

 TBD

 

Panel
Section
Column
width50%

 Previous: 7. Blueriq Actuators

Column

Next: 9. Runtime cluster limitations