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

Overview

This page addresses potential compatibility issues when upgrading from pulse™ 2.6.x to 2.7.x. We strive to make upgrades as automatic and compatible as possible, however there may be some slight changes that affect some customers. Possible issues are outlined below.

Running As a Service

Prior to 2.7.x, pulse™ used the Java Service Wrapper library to run as a service on both Windows and Unix platforms. From 2.7.x onwards we have dropped the Java Service Wrapper in favour of Apache Commons Daemon on Windows and direct integration with new init systems on Unix (particularly Linux). This change has the following advantages:

  • Commons Daemon allows Pulse to run as a service with a 64-bit JVM on Windows, a long-standing request.
  • Commons Daemon on Windows provides a simple configuration and monitoring GUI.
  • Linux users can move away from the older SysV-style init scripts to newer tools like systemd or upstart (note that we still support SysV-init for those that require or prefer it).

The downside of this change is that it affects unversioned components (files outside of $PULSE_HOME/versions) of your pulse™ agent installation which cannot be updated for you via an automated agent upgrade. For users running an agent pool this has two implications:

  1. Automated agent upgrades will not work at all from versions earlier than 2.6.20, as the agents will reject updates that include new unversioned components.
  2. Automated agent upgrades will work from 2.6.20 or later, but will not install the new service components. Agents upgraded this way will continue to use the Java Service Wrapper until you intervene manually.

To take advantage of the new service components on existing agents you must manually upgrade them to 2.7.x. On Windows the best approach is to uninstall the earlier version then use the Windows installer to install the new version including the Commons Daemon service and monitor GUI. On other platforms simply unpack a new archive to replace the existing version. Note that manual intervention is not required if you are happy with the current service components, instead you can just upgrade to the latest 2.6.x build and then upgrade again to 2.7.x. All agents will update automatically and continue to work as before. If you are managing a large agent pool you may wish to do this first, then perform manual upgrades on an as-needed basis over time (e.g. as you need/want to switch Windows agents to a 64-bit JVM, or switch Linux agents to systemd).

For more details on the new service components refer to Running as a Service.

Properties Referencing Other Properties

In this release we've fixed a bug in the expansion of self-referencing properties (i.e. properties whose value references the same property). As part of this fix, the evaluation of property values has become more strict in general. Some things that used to work by chance, rather than design, will no longer work. This is most likely to appear as an unresolved property reference in the value of another property. If you start to see this after upgrading to 2.7.x, please check the order in which you have defined your properties. References to properties defined earlier will work, references to properties defined later will not work (though they may have previously). See the Properties page for more information about the order in which properties are evaluated.

Xcode Output Processor

The Xcode output post-processor has been tuned to suite newer versions of Xcode and the clang/llvm toolchain.  If you have configured existing processors via the Pulse UI, these will not be updated automatically when you upgrade (so they continue to work as before).  To switch to the newer version you can recreate any processors you have defined and they will adopt the new regular expressions.  In particular, you may want to recreate the "xcode output processor" defined on the global project template, and re-apply any of your own tweaks to the expressions.

Allowing Cleanup Outside of the Data Directory

Prior to pulse™ 2.7.4 a system property named pulse.delete.outside.data had to be set to allow agents to automatically clean up directories not nested within $PULSE_DATA. This is a safety measure to help prevent unwanted file deletion. If you have been using this property, from 2.7.4 onwards you should instead enable the new "allow cleanup outside data directory" option under each agent's "storage configuration" (you can use templates to enable this for many agents in one place). The system property still applies to cleanup done on and by the master, so you may want to retain it there.

  • No labels