MIchael,
Some good questions, I will answer what I can.
When you execute the upgrade (or an install also), you can pass all your property=value settings as -D parameters on the command line. You could see where that gets very long and messy after a while.
So instead you can pass a .properties file containing all your property=value settings.
That means that to run a silent upgrade using an upgrade.properties file you would execute:
./setup.bin -i silent -f <path to upgrade properties file>
Of course you need to have modified the properties file appropriately for your agent.
As far as installing a fresh new agent side-by-side with an old one, switching the workload over to the new one, and eventually removing the old one.
That is still a valid approach and there is nothing wrong with that and I assume you understand it well.
Using upgrade has the effect of modifying an already installed agent (replace binaries/jars, replace or point to a new JRE, update agentparms.txt (as needed), fix any other generated files (as needed), etc. But before doing that, the install/upgrade will make a backup tar file of all the affected files prior to doing the upgrade.
However, there is no automated customer use of the backup tar file as yet. If you needed to revert to the backup, it would be a manual process and I am not entirely sure of the steps myself. (The install does use the backup file internally if an error occurs during the upgrade.)
The question about "How did you handle the new JRE issue?", I cannot answer. But I can explain it some.
Oracle has changed the legal ability of a product to ship Oracle's versions of the JRE. Basically they want their money. As such, Broadcom/CA had to modify stuff.
We no longer ship any Oracle JREs. We typically either ship the AdoptOpenJRE, an OS vendor supplied JRE, or no JRE depending on the platform.
We also modified the installers so that a customer can specify an external (customer installed) JRE on all platforms.
The external JRE support allows a customer to continue to run with Oracle JREs if they prefer (assuming they follow the new licensing) and/or it allows a customer to have a common JRE on a machine and not have a variety of products installed, each potentially installing their own JREs. There are space, licensing, security, virus scanning, etc implications to some customers in this area. So now we provide the customer provided JRE as an option.
All the JREs we ship should be legal for a customer to use.
Can you use AdoptOpenJRE on solaris? If they provide one, then yes you can install it and instruct the agent to use it. However, since we can still legally ship the vendor supplied JRE on that platform, that is what we are doing.
I hope this helps some.
Original Message:
Sent: 01-23-2020 04:41 PM
From: Michael Bieganski
Subject: upgrading a v11.3 agent to a v11.4 sp1 or v11.5
Hello Community, I have some questions regarding some apparent nuances in upgrading from a v11.3 windows or sun cybAgent to a v11.4 SP1 or v11.5 agent. (ESP, non-Autosys type agents)
For a new installation, to install silently you'd use the usual command:
./setup.bin -f path/unix_installer.properties
Starting with CA Workload agents v11.4 SP1 and v11.5, a new file comes shipped, "upgrade.properties"
From what I'm seeing however in the documentation, it shows that to UPGRADE silently you'd use the command:
./setup.bin -i silent -DACCEPT_EULA=ACCEPT -DAGENT_UPGRADE_PATH=<path to existing agent directory>
Apparently the upgrade process looks at your current agent path and acts accordingly.
Upgrading in this manner, i.e. in place with simply issuing a command is totally foreign to me. I usually remove an old agent and install a newer one, or turn off the older one and install from a totally different folder. So this sounds promising.
Any gotchas with upgrading in place like this?
How would you back it out if need be? (it apparently makes a backup for you, but is it a tar file? What does one do with that?)
Also, where/how does this new "upgrade.properties" file actually come into play since you don't explicitly specify it anywhere
in the upgrade command. The sample upgrade.properties only illustrates a couple new parms, but something like
AGENT_UPGRADE_FORCE or UPGRADE_BACKUP_LOCATION might come in handy from time to time.
So, how does one incorporate the "upgrade.properties" file into the process?
Lastly, For v11.5 installs or upgrades, ...has anyone installed a v11.5 yet? If so, how did you handle the new JRE issue ?
I understand the v11.5 agents no longer are shipped with the Oracle JRE. I understand that Broadcom bundles a different
JRE, "AdoptOpenJRE" that you can point to in the installer.properties somehow. But where it is legal to use is unclear to me.
Can you use the new "AdoptOpenJRE" only for windows & linux agents or can you also specify AdoptOpenJRE for solaris as well?
thanks!