Hi,
I just completed an Octopus 3.3 server migration due to our organisation migrating to a new cloud provider. I followed the simple steps of backing up the SQL server on the original server and restoring it to the destination server and then using that database (with the correct master key) when performing the Octopus server install. Firstly well done to the team for providing such a well designed product which simplifies these types of operations!
However I had an issue after the Octopus Server install. The Octopus Service failed to start. The Application Event Logs contained errors. One of them was:
Could not find a part of the path ‘O:\Octopus\TaskLogs’. (See inner exception for details.)
Autofac.Core.DependencyResolutionException: An exception was thrown while invoking the constructor ‘Void .ctor(Octopus.Shared.Time.IClock, Octopus.Core.RelationalStorage.IRelationalStore, Octopus.Core.Model.Logging.ILogEncoder, Octopus.Shared.Util.IOctopusFileSystem, Octopus.Shared.Util.ISemaphore)’ on type ‘ServerLogStorage’. —> Could not find a part of the path ‘O:\Octopus\TaskLogs’. (See inner exception for details.) —> System.IO.DirectoryNotFoundException: Could not find a part of the path ‘O:\Octopus\TaskLogs’.
I figured out that on the old Octopus Server, the installation path was the “O:” drive but on the new Octopus Server, the installation path was the “D:” drive. In order to get the Octopus service to start, I needed to edit rows in the “Configuration” SQL table. I did a search/replace of “O” with “D” and everything worked fine after that.
Suggesting that the setup process needs to take this into account. Maybe when the database is attached, the relative paths need to be updated?
Another issue I had was that all the Offline Package Drop folder paths needed to be updated because the server name was different. Maybe there could be a base folder for offline package drops so that the location only ever needs to be updated in one place if it moves?
Thanks!
Larry