This post is co-authored by Riccardo Rossi and Eliana Cerasaro.
A new IBM Workload Scheduler (IWS) release which contains new appealing feature that fit perfectly for your business has just been delivered but you are blocked by the idea to manually migrate all the IWS agents on your environment? Don't worry about that, IWS 9.3 introduces a new way to upgrade the IWS agent with a Centralized Agent Update feature that will let you to migrate to the new agent directly form the Dynamic Workload Console with just a click. And this is not all, the IWS 9.3 Fixpack1 introduces also a new job type that will let you to schedule your centralized agent update on a bounce of agents using all the scheduling features available on IWS.
How it works
The Centralized Agent Update feature has been introduced in the release 9.3.0 so first of all you have to identify if this feature applies to your environment: you need at least a Master and Agents (both Dynamic and FTA) at that level, this will not help you to migrate from old releases but after the first migration done manually to reach the 9.3 you'll have the feature available for each future agent fixpack or major release. This surely is a good reason to migrate from old releases to 9.3.0.
But the 9.3.0 doesn't give you the chance to schedule your centralized agent update using the new job type available, so to use this feature the starting point is a little bit forward, 9.3.0 with fixpack1 (126.96.36.199).
So for this article we consider as starting point, an environment with a Master 188.8.131.52 On Premises and agents (both Dynamic and FTA) at level 9.3.0 or 184.108.40.206.
So here the first question is: "OK, this is cool, but 220.127.116.11 is the latest available version for IWS, so what I'm going to update to?". The answer is easy, you have prepared your environment to be ready for any release upgrade or fixpack update in the future.
Defining Centralized update agent job
Now we can leave back the previous tedious, but important, clarifications and we can start with the definition of the new job to schedule the centralized agent update
In the Dynamic Workload Console you can create a new job called "Centralized Agent Update" this job MUST run on a Dynamic agent , but you do not need to install a new Dynamic agent to execute this job, you can use the Dynamic agent always available on the Master itself. When this job is added to the plan, it will trigger on the Master the agent update of the selected agents at the scheduled time.
The definition of this new job you to configure some basic information: the Master server with username and password to connect to, so that during the execution this job can contact the Master to trigger the update. The job definition contains also the list of agents (either Dynamic and FTA) that will be updated.
Now the first choice: the number of agents that you want to update at the same time. Here the best practice is to select a number of agents that will be easy to monitor when we'll go to analyze the results; the suggestion is to experiment the feature with 2 agents only and then move up until you reach the number of agents that better are suitable for you.
A clarification it's a must now, this new job type has only the capability to "trigger" the agent update in an asynchronous way, not to monitor the results of all updates; this means that this job will start and complete successfully in few instants, meaning that the agents update has been triggered successfully for all agents. Then the agents autonomously and asynchronously will start and complete the update.
Monitor the centralized agent update job
In the Dynamic Workload Console there is a page to monitor the operator messages, during the centralized agent update all the agents will send messages about the status of their update in this operator console. All the messages coming from different agents performing the update are interlaced in this console, this is the reason way you have to experiment the right number of agents you want monitor and check on this console simultaneously. By the way there is a useful filter on this console that will let you to group the messages by agent name to easily check the status.
Analyze agent update errors
In order to understand what was wrong during centralized agent update the monitor operator message is the right place: let's take a look to a failed update:
In this case the new agent package was successfully downloaded to target agent and the update failed locally due a missing prerequisite: just go to the agent and check the specified log file in order to understand what is the issue.
Stefano Manocchio is currently a Staff Software Engineer and is working as DevOps specialist for the IBM Workload Automation on SaaS. Stefano has been working at IBM since 2002 as software developer for many products. He has a background in computer science technologies. Follow me on Linkedin
Eliana Cerasaro has 10 years of experience working in design and implementation for IBM Workload Automation area. She is a software engineer at the IBM Labs in Rome, Italy.
Riccardo Rossi joined IBM in 1998 with the goal to automate the manual test suite for the IBM License Use Management product. During these years Riccardo worked for many IBM products of the IBM Rome Laboratory covering different positions in the development life cycle, level 3 service support, test automation leader, product developer and designer, acquiring a deep knowledge in the development cycle. Riccardo is currently an Advisory Software Engineer working as scrum master and developer for the IBM Workload Automation for distributed platforms product (on-premise & SaaS).