Concern about new feature in 2.5: "Deployments no longer attempted to out of date Tentacles"

We saw that you added this check to make sure that old tentacles were not being used in version 2.5+. We have a lot of concern with this validation. With this check this means that we would have no way to check if the new tentacles work correctly before actually updating them. In the past we have found problems with tentacles which caused us to have to rollback the upgrade until certain bugs could be fixed. If this were the case with this new update it would mean we could not deploy anything until the problem with the tentacle was fixed. Is there a way to turn off this check so that old tentacles could be used? I understand that tentacles should be updated, but forcing people to upgrade things blindly isn’t the best way.

Hi Brent,

Thanks for getting in touch! There’s two risks here:

  1. As you’ve highlighted, the new Tentacle might be buggy, so it might be nice to try and deploy with old versions as a test
  2. Someone forgets to update, and Octopus assumes Tentacle is latest, and sends the wrong information resulting in a broken deployment (possibly a production deployment)

I felt that #2 was a more important risk to mitigate than #1, but I think we also have a solution for #1. One thing you can now do is to upgrade a single environment at a time (you don’t have to update all tentacles). So the process for adopting a new Octopus release would be:

  1. Install the new Octopus
  2. Upgrade a small test environment
  3. Deploy a test deployment

If it goes wrong and you need to roll back, you can just reinstall the old Tentacle on that small number of machines.

(The validation checks that all machines in the target environment are up to date, not all machines in all environments)

Hope that helps!


This means that if we install a new version of octopus deploy and discover a bug in a tentacle we would have to rollback our entire instance of OD in order to deploy any code to any region because of this check. I’m afraid this causes us to adopt the newest version much slower. The only way I can see this working for us is to create dummy deployments to regions and practice deployments in this region. And then of all looks stable for some time. Try and upgrade the newest OD. I feel this still presents a rather deep pain point for us and I assume others. Unless I am missing something. One other option would be to warn for out of date versions 1 version behind and not allow versions two version behind which would be something we could work with.

Brent Montague
Software Engineer
Sent from my iPhone