Octopus server v2 promoting to the wrong environment

Legacy Uncategorised
1

Hi.

After migrating to Octopus v2 releases are being promoted to the wrong environment. That is:

1- Select the Continuous Integration environment (Integration), which contains the latest version built in the TeamCity server.
2- Click "Promote"
3- Select any of the other environments in the drop down (SomeDev).
4- Leave all the default options and click Deploy release.

Expected behaviour: the deployment is triggered for the right environment (SomeDev) and the correct tentacle is targeted (somedev-services).
Actual behaviour: the deployment is triggered for the right environment (SomeDev) BUT the original tentacle is targeted (integration-services).

Looking at the deployment logs, the following fragment appears for both environments, with exactly the same SQ-TH-BASE-3D9303A7, which doesn’t seem fine to me.

@@@
Upload package to https://integration-services:10933/
12:21:07Info
Uploading OURPACKAGE.1.0.0.4315 (72.37 MB) to SQ-TH-BASE-3D9303A7
12:21:55Info
Package OURPACKAGE 1.0.0.4315 successfully uploaded to tentacle SQ-TH-BASE-3D9303A7
@@@

The way we manage our environments is:

1- We create a BASE Virtual Machine (TH-BASE), on which we install the tentacle and all the other dependencies we have.
2- To create a new machine, we clone that TH-BASE machine and run the following script to register the tentacle:
@@@
& “C:\Program Files\Octopus Deploy\Tentacle\Tentacle.exe” new-certificate
try
{
Write-Output “Registering Tentacle…”
& “C:\Program Files\Octopus Deploy\Tentacle\Tentacle.exe” register-with --server "https://octopus"
–apiKey="${octopusApiKey}" --role "serviceshost"
–environment “${octopusEnvironmentName}” --comms-style TentaclePassive
–force `
–console
Write-Host "Tentacle registered"
break
}
catch
{
Write-Host “Failed to register tentacle”
}

& “C:\Program Files\Octopus Deploy\Tentacle\Tentacle.exe” service --stop
& “C:\Program Files\Octopus Deploy\Tentacle\Tentacle.exe” service --start
@@@

This is the same approach we used with Octopus v1 and we didn’t have any issues.

Cheers

2

Hi,

Thanks for letting us know about this and sorry for the trouble.

In 2.0 we had to introduce a new concept, which we’ve called the SQUID, which has to be unique per machine.

I would recommend that instead of installing and configuring Tentacle and then cloning, you install the Tentacle MSI, then clone, and then configure it.

If you walk through the configuration wizard once, at the end you can use “show script” instead of performing the configuration to see exactly the script to run. You can then use this script when you prepare the cloned VM’s, and they’ll all get a unique SQUID.

Currently there’s no way to reset a SQUID from the command line; we’ll add this next release.

Hope that helps, and sorry once again for the breaking change.

Paul

3

I’ve recorded an issue here to address this in our next release:

Paul

4

Hi. Thanks for your reply.

I can confirm the issue was related to having duplicated SQUIDs due to cloning the VMs with the tentacle configured.

While having a way to reset only the SQUID will be useful, we still need to generate a new thumbprint, etc, so, we solved the issue by running the whole configuration script as explained in the “Example: Listening Tentacle” section at http://docs.octopusdeploy.com/display/OD/Automating+Tentacle+installation

Rodolfo

5

Hello,

I ran into this issue recently, where I used cloned VMs to create a new environment. The solution was easy enough – to delete the tentacle instance on the clones and recreate. Before I realized it was an issue though I attempted to deploy to the new environment, and OD deployed to the old one from which the clones had been created.

Fortunately it wasn’t a huge problem, but it could have been, and it did lead me to wonder if Octopus could warn you when you add a duplicate SQUID to a new environment. I imagine there are legitimate times that a person would want to do this, but it seems that if there are two differently-named machines in different environments with the same SQUID, that could at least pop up a warning?

Louis

6

Hi Louis,

Thanks for getting in touch! As of 2.5 we now strictly do not allow deployments when SQUIDs are duplicated.
We also considering it a breaking change due, as you said, to there being cases where people would want this.
This was the ticket: https://github.com/OctopusDeploy/Issues/issues/923

Thanks!
Vanessa