I am trying to deploy to two separate Linux machines with the same role, but only one will run at a time.
Cannot start this task yet because “ServerTasks-218599” (has a write lock) tasks are currently running and this task cannot be run in conjunction with any other tasks. Please wait…
The ServerTask is the current deployment, but it should not be blocking the deployment on the second machine.
I had this issue as well, through trial and error I found out that when I cloned a server, either Windows or Linux, I had to re-install the Octopus Tentacle. Without the re-install of the tentacle Octopus thinks it is the same registered server.
Well, that would do it. Thanks for the quick answer.
Hi @chris_mullins & @Bruce_Foust,
It looks like everything is in order here! I’m just stopping in to say that we currently have a GitHub issue to address this.
I’ll add this conversation to the issue as a source so the devs can easily see it.
Let me know if you have any thoughts or questions here.
Is there a work around for this?
Currently we do not have a work around for this specific issue. As the issue is related to deploying in parallel to Targets which share a Thumbprint. I believe the only option currently would be to make sure that no targets you wish to deploy in parallel share a Thumbprint until this issue is resolved.
Do you have a timeline for a fix? Where does the Thumbprint come from in Linux? Does it come from the ssh user’s certificate? If it isn’t from the user, how would I change it?
Sorry about that, I could have explained that much better. Octopus uses the fingerprint from your SSH targets public key. When Octopus connects to the SSH target, if you used the discover method then Octopus will automatically get the fingerpint from the target.
Restarting the target is a way to free up any locked tasks, however the issue still remains that we can not deploy to more than one target sharing a fingerprint simultaneously.
We have a bit more information on this with some better explanations in our documentation.
Let me know if you have any further questions here and again, I’m sorry for the confusion I caused here.
We are having the same issue, where all our deployment targets have the same SSH key. We started having the problem after upgrading the calamari to 2018.3.3.