We’re planning a 2.6 --> 3.x upgrade and we would like to now if it’s possible to have 2.6 and 3.x octopus server instances running together on the same VM.
A big bang upgrade is to risky - arond 10 different client environments and lots of tentacles - and runing 3.x from a new VM with new ip-numbers involves updating several VPN connections and updating access-lists.
So if running 2.6 and 3.x together on the same VM is possible this would be our best upgrade path. This will save us a lot of time, coordination and changes third party platforms.
Hi
A question with regards to the upgrade with a new instance as recommended.
Reading the documentation it says the following:
“This is the recommended way of performing an upgrade for larger installations. It gives you the opportunity to verify that your Tentacles have been successfully upgraded, and allows you to more easily roll back if you have any issues.”
The thing is we have to upgrade all the tentacles first, so if something doesn’t work and we would like to roll back for some reason - is there an easy way to roll-back the tentacles too?
Also is there a plan to enhance the “Hydra” utility to allow upgrading the tentacles automatically with the more advanced options? for instance most of our tentacles are installed to run with a different user account (different environments have different accounts), and we have hundred of tentacles - so do we have to write our own tentacle distribution for upgrade and in the worst case roll back too?
I’m sorry, Hydra doesn’t support installing Tentacles as a custom account, and we don’t have any immediate plans to add that capability. Our hope is that Tentacle upgrades will rarely be required in the future. We created the concept of Calamari, essentially removing the brains from Tentacles, giving them much less responsibility.
And likewise there is no automated bulk rollback for Tentacles.
To try and solve the problem above we came up with the following solution:
prior to upgrade ran a script from the script console on all of the tentacles in all the environment and got the account that the tentacle is running with.
created an intermediate script (which i ran on my box) toparse the log of the output above. The output of this script would be a map file with a list of:
tentacle name, user, password.
created another script which will run from Script Console on all the machines in all the environments which this script will: traverse the map file above, and if the machine name that the script is running on appears in the map file - reconfigure the new 3.x tentacle which is now running under local system after Hydra to be back the account that the map file states.
