Introduction

  • JS7 - Download offers current releases of the product for download. For initial installation see JS7 - Installation
  • Any updates or upgrades are performed using the installation archive .tar.gz/.zip files provided for initial installation of newer releases. Instructions provided by the JS7 - Installation section apply to updates and upgrades.
  • JS7 follows semantic versioning, therefore the wording is applied as follows:
    • JS7 - Update to newer JS7 maintenance releases: switch to a maintenance release within the same branch, for example within minor release 2.2
      • update from 2.2.1 to 2.2.2
      • update from 2.2.0 to 2.2.2 (the latest maintenance release includes any fixes of previous maintenance releases)
    • Upgrade to newer JS7 releases: switch to a newer minor release, for example from minor release 2.1 to 2.2
      • upgrade from 2.1.0 to 2.2.0
      • upgrade from 2.1.1 to 2.2.2

Upgrade

Compatibility

Before updating users should identify the version in use by JS7 products and the indicated compatibility, see JS7 - Compatibility Indicator.

Applicability

  • The JOC Cockpit and the Controller are required to use the same minor release, for example 2.2.
  • Existing Agents can continue to be operated with newer Controller releases within the same minor release only:
    • An older Agent maintenance release 2.2.1 will work with a Controller maintenance release 2.2.2.
    • A newer Agent minor release cannot be used with an older Controller minor release: for example, an Agent 2.2 will not work with a Controller 2.1.
    • An older Agent minor release cannot be used with newer Controller minor release: for example, an Agent 2.1 will not work with a Controller 2.2.

The above rules generally apply. However, such rules can differ for specific minor/maintenance releases.

The information of the JS7 - Compatibility Indicator about compatibility is authoritative.

Order of Products

  • In a first step update JOC Cockpit,
  • in a second step update Controller,
  • finally update Agents.

Upgrade Procedure for Use of Container Images

For container images provided for JOC Cockpit, Controller and Agents the following procedure applies:

Consider that the above procedure does not apply if you build your own images, see JS7 - Build Container Images. Consider to map the steps explained with Upgrade Procedure for Headless Installation On Premises.

Upgrade Procedure for Installation On Premises

Procedures include that upgrades can be performed automatically using installation scripts:

In addition, users can choose to manually upgrade as explained by the installation instructions.

Both options are indicated with the below upgrade procedures.

JOC Cockpit

  • Consider instructions from JS7 - JOC Cockpit Installation On Premises.
  • Take a backup of the JOC Cockpit's installation directory.
  • Option 1: Automated Upgrade
  • Option 2: Manual Upgrade
    • Extract the installer archive .tar.gz/.zip file. This will create a sub-directory that includes the maintenance release number, for example joc.2.2.2.
      • Users basically can re-use an existing joc_install.xml installer response file from a previous installation, however, users should check for changes, for example new or changed installer options that are available from the joc_install.xml file after extraction of the installer archive. If in doubt copy settings from a previous joc_install.xml file to the new version of this file.
      • Consider to copy additional resources to the directory of the extracted installer archive, for example to joc.2.2.2
        • any JDBC Drivers that you downloaded individually for installation with a previous JOC Cockpit release,
        • the Hibernate configuration file that holds the database connection and that has been used for a previous installation,
        • the JS7 license key *.pem file if JS7 is operated with a Commercial License. 
    • Stop the JOC Cockpit daemon (Linux) or service (Windows) of any JOC Cockpit instances using the same database.
    • Take a backup of the JS7 - Database schema. During upgrade changes to the database schema might be applied that prevent to rollback to the previous JOC Cockpit release.
    • Run the JOC Cockpit installer
      • Invoke the installer script in the same way as for installation of a previous release, for example
        • ./setup.sh|.cmd joc_install.xml
        • ./setup.sh|.cmd -u joc_install.xml
    • Start the JOC Cockpit daemon (Linux) or service (Windows)

Controller

  • Consider instructions from JS7 - Controller Installation On Premises.
  • Take a backup of the Controller instance's installation directory.
  • Suspend all orders.
  • Stop the Controller:
    • Standalone Controller
      • Stop the Controller instance's daemon (Linux) or service (Windows).
    • Controller Cluster
      • Take a note which Controller instance is the active node before stopping Controller instances.
      • Stop both Controller instances' daemon (Linux) or service (Windows).
      • Stop the Cluster Watch Agent daemon (Linux) or service (Windows) if an Agent is used as a Cluster Watch.
  • Option 1: Automated Upgrade
  • Option 2: Manual Upgrade
    • Extract the installer archive .tar.gz/.zip file from a neutral directory not related to the current Controller installation. This will create a sub-directory that includes the maintenance release number, for example controller.2.2.2.
    • From the existing Controller installation directory move or remove the lib directory.
    • Copy the lib and bin sub-directories from the extracted installer archive to the Controller instance's installation directory. This will replace the previous lib sub-directory and will overwrite the existing bin sub-directory from the new release. The Controller's instance start script that can contain individual settings, is not included with the installation archive and therefore will not be overwritten, see JS7 - Controller - Command Line Operation.
    • For a Controller Cluster
      • consider to perform this step for both Controller instances.
      • update the Cluster Watch Agent as explained below and start the Cluster Watch Agent. This step is not performed if JOC Cockpit is used as a Cluster Watch.
  • Start the Controller. For a Controller Cluster start both Controller instances.
  • Update Agents.
  • Resume all orders.

Agent

  • Consider instructions from JS7 - Agent Installation On Premises.
  • Take a backup of the Agent's installation directory.
  • Suspend orders related to the Agent in question.
  • Stop the Agent
    • Standalone Agent
      • Stop the Agent instance's daemon (Linux) or service (Windows). This can be performed using the Agent's installation scripts.
    • Cluster Agent
      • Take a note which Director Agent instance is the active node before stopping Agent instances.
      • Stop the Primary and Secondary Director Agent instance's daemon (Linux) or service (Windows).
  • Option 1: Automated Upgrade
  • Option 2: Manual Upgrade
    • Extract the installer archive .tar.gz/.zip file from a neutral directory not related to the current Agent installation. This will create a sub-directory that includes the maintenance release number, for example agent.2.2.2.
    • From the existing Agent installation directory move or remove the lib directory.
    • Copy the lib and bin sub-directories from the extracted installer archive to the Agent's installation directory. This will replace the previous lib sub-directory and will overwrite the existing bin sub-directory from the new release. The Agent's instance start script that can contain individual settings is not included with the installer archive and therefore will not be overwritten, see JS7 - Agent Command Line Operation.
    • For an Agent Cluster consider performing this step for all Agent instances in the cluster.
  • Start the Agent.
  • Resume orders for the related Agent.

Troubleshooting

Controller Cluster

Should some of the above explained steps to update/upgrade a Controller have been missed, for example if the Secondary Controller is still active while the Primary Controller is updated or upgraded then the Cluster can become unavailable. In this situation apply the following procedure:

  • Determine the Controller instance that is active.
  • Stop both Controller instances.
  • From the Controller instance that previously was the active node copy the contents of the  state directory to the directory with the same name of the Controller instance that was previously the standby node. This operation can be considered a manual step for synchronization of the Controller Cluster.
  • Start both Controller instances.

Agent

Should some of the above explained steps to update/upgrade an Agent have been missed, then Reset the Agent having updated/upgraded the Agent's installation directory.

The user account's menu in the right upper corner of any JOC Cockpit page offers the Manage Controller/Agents operation:


The respective page for Controller/Agent management offers the operation to reset an Agent:


Explanation:

  • The Reset operation comes in two flavors:
    • Reset: the Agent is requested to perform a restart. This operation is applicable if no orders are started or are running with the Agent.
    • Reset Forced: the Agent is forced to perform a restart and to drop its journal. The Controller will then re-deploy scheduling objects such as workflows to the Agent.
  • The Reset operation can require 10 to 60 seconds depending on the time required to stop and to start the Agent.