How to perform Rolling Upgrade through TIBCO ActiveMatrix Administrator Command Line Interface
Article ID: KB0087514
Updated On:
| Products | Versions |
|---|---|
| TIBCO ActiveMatrix Service Grid | - |
| TIBCO ActiveMatrix BusinessWorks Service Engine | - |
| Not Applicable | - |
Description
Description:
Steps to perform rolling upgrade through TIBCO ActiveMatrix Administrator Command Line Interface
Steps to perform rolling upgrade through TIBCO ActiveMatrix Administrator Command Line Interface
Issue/Introduction
How to perform Rolling Upgrade through TIBCO ActiveMatrix Administrator Command Line Interface
Resolution
Problem Description
1). Specify on which nodes the upgrade (new version) should NOT be deployed.
<target name="disable.upgrade.app" description="Specify the nodes on which the new version must NOT be deployed at this time">
<AMXAdminTask propsFile="${remote-properties.file}"
action="disable" dataFile="${basedir}/jv.helloworld1.soa.deployment-config.xml"
objectSelector="Environment/Application/Node['SOANode1']"
overwrite="false" merge="false"
createIfNotExists="true" force="false" failOnError="true" />
</target>
Option B:
<target name="enable.upgrade.app" description="Specify the nodes where you want to deploy the upgrade, leaving all other nodes at the old versions">
<AMXAdminTask propsFile="${remote-properties.file}"
action="enable" dataFile="${basedir}/jv.helloworld1.soa.deployment-config.xml"
objectSelector="Environment/Application/Node['SOANode1']"
overwrite="false" merge="false"
createIfNotExists="true" force="false" failOnError="true" />
</target>
Data File Modifications:
*****************************************************
You need to add the node element to your data file (under the hierarchy "Environment/Application"). Refer to the attached file (Filename:sampleCLI_RollingUpgrade.zip).
Build File:
objectSelector="Environment/Application/Node[@name='Node1']"
Deployment-config File:
<Node name="Node1" environmentName="DevEnvironment"/>
Case 2:
- Make sure deploy.app target has the following attribute.
options="handleDependencies"
- The enable upgrade task has not been completely tested as there are issues using the same and therefore the recommended one is to use "disable upgrade task" as demonstrated in the attached sample scripts.
Comments: After the rolling upgrade (through CLI), you will find the excluded node in an out-of-sync state.This is because on the excluded node, a new version feature is in the "marked for install" state and the old version is in a "marked for uninstall" state, which means the node is still running on an old version which is expected. Eventually, all nodes need to be upgraded, so this should not be an issue.
===============
Rolling upgrade through the Command Line Interface is currently not documented and there are no sample scripts available to demonstrate how it can be accomplished.
Solution
Rolling upgrade through the Command Line Interface is currently not documented and there are no sample scripts available to demonstrate how it can be accomplished.
Solution
======
Build file modifications:
**********************************************************************
Below are two targets added to the build file. For a rolling upgrade, you have two choices for CLI scripting:
Build file modifications:
**********************************************************************
Below are two targets added to the build file. For a rolling upgrade, you have two choices for CLI scripting:
1). Specify on which nodes the upgrade (new version) should NOT be deployed.
2). Specify on which nodes the upgrade (new version) should be deployed. You can select either of these targets as per your requirement.
Option A:
Option A:
<target name="disable.upgrade.app" description="Specify the nodes on which the new version must NOT be deployed at this time">
<AMXAdminTask propsFile="${remote-properties.file}"
action="disable" dataFile="${basedir}/jv.helloworld1.soa.deployment-config.xml"
objectSelector="Environment/Application/Node['SOANode1']"
overwrite="false" merge="false"
createIfNotExists="true" force="false" failOnError="true" />
</target>
Option B:
<target name="enable.upgrade.app" description="Specify the nodes where you want to deploy the upgrade, leaving all other nodes at the old versions">
<AMXAdminTask propsFile="${remote-properties.file}"
action="enable" dataFile="${basedir}/jv.helloworld1.soa.deployment-config.xml"
objectSelector="Environment/Application/Node['SOANode1']"
overwrite="false" merge="false"
createIfNotExists="true" force="false" failOnError="true" />
</target>
Data File Modifications:
*****************************************************
You need to add the node element to your data file (under the hierarchy "Environment/Application"). Refer to the attached file (Filename:sampleCLI_RollingUpgrade.zip).
Aample scripts provided here.
Case 1:
Case 1:
If you want to enable/disable upgrade only in Node1, then provide the objectSelector for enable/disable upgrade target (in build file) as shown below and then update the data file with the node element as shown in the following example.
Build File:
objectSelector="Environment/Application/Node[@name='Node1']"
Deployment-config File:
<Node name="Node1" environmentName="DevEnvironment"/>
Case 2:
If you want to enable/disable upgrade for multiple nodes, then modify the objectSelector for enable/disable upgrade target as shown below and update the data file to have both node elements.
Build File:
objectSelector="Environment/Application/Node['Node1'] | Environment/Application/Node['Node2']"
Deployment-config File:
<Node name="Node1" environmentName="DevEnvironment"/>
<Node name="Node2" environmentName="DevEnvironment"/>
**************************************************************
Important points to be noted:
objectSelector="Environment/Application/Node['Node1'] | Environment/Application/Node['Node2']"
Deployment-config File:
<Node name="Node1" environmentName="DevEnvironment"/>
<Node name="Node2" environmentName="DevEnvironment"/>
**************************************************************
Important points to be noted:
- Following the above mentioned example, the order of upgrade tasks should be as follows. The disable/upgrade task should be always given after the upgrade.app target.
upgrade.app, disable.upgrade.app/enable.upgrade.app
upgrade.app, disable.upgrade.app/enable.upgrade.app
- Make sure deploy.app target has the following attribute.
options="handleDependencies"
- Note that the distribute.app should have the action as "add" instead of "set", otherwise it will remove the node from the distribution.
- Change to: force="false", overwrite="false" & merge="false" in all places.
- Remove unused targets that may not be relevant to the rolling upgrade - such as "disable.features".
- The enable upgrade task has not been completely tested as there are issues using the same and therefore the recommended one is to use "disable upgrade task" as demonstrated in the attached sample scripts.
Comments: After the rolling upgrade (through CLI), you will find the excluded node in an out-of-sync state.This is because on the excluded node, a new version feature is in the "marked for install" state and the old version is in a "marked for uninstall" state, which means the node is still running on an old version which is expected. Eventually, all nodes need to be upgraded, so this should not be an issue.
Additional Information
Document defect TAP-12984 has been filed to include these steps in product documentation.
Attachments
Feedback
Yes
No
Powered by
