We are developing our repaving scripts, including installation of a polling tentacle that is already registered with the Octopus Server. We hoped that we would be able to just call ".\Tentacle.exe" register-with --instance using the same instance name and it would overwrite the previous information stored on Octopus. From what we are seeing, there are no errors, however whenever Octopus server tries to execute something against the polling tentacle it times out.
Is it possible that either the certificate or the Subscription ID i.e. poll://5maz6lw4kj8zjmxkzzrr/ for the old polling tentacle is getting cached on the Server? If so, what is the proper way to implement a repaving strategy that will not uninstall the original tentacle prior to repaving?
To make sure I understand correctly, you’re attempting to make use of the ".\Tentacle.exe" to update an already existing polling tentacle to start communicating with a new Octopus instance?
Yes. The VM hosting the tentacle prior to repave is dropped with no processing. We reinstall a polling tentacle on a clean image (using a very similar script to here) and we call register-with --instance using the same name that was used for the prior instance blown away during the repave. We use a single certificate for all of our tentacles, so that is reused.
To be clear, the deployment targets are never deleted on the server. We did not call deregister-from, which I am now looking at and thinking this may be the issue…
I seem to be having issues re-creating your scenario. I’ve registered a polling tentacle with my Octopus instance as Polling1 on my first VM. I then get rid of that VM. On a second clean VM, I register a polling tentacle using the same instance name, making sure to pass the --force flag in the register-with command. When I do a health check, I receive success.
Would you be able to send me a sample of the exact commands you’re using, minus any sensitive information?