So I understand that the project variable Octopus.Action.MaxParallelism (we have set to 24) will overide any setting we have for rolling deployment, in this case we would like to be set to 1.
Issue being, other than rolling deployments, we would like max to be 24 to allow all nodes to be deployed to at the same time instead of it hitting the default max and deploying in sets.
So how do we have our cake and eat it too?
I don’t follow the recommendation provided in the warning “We recommend either adding a prefix to your step template variables, or changing the names of the variables on your project”
You cant change the name at the step level and if you change it in the project variable. Will it still know what the variable means?
Also why does a project level variable override a step variable in the first place?
A side note we also have Octopus.Acquire.MaxParallelism set to 24 as well. Not sure how that plays into this.
Hi @brian.cooperider
Thanks for reaching out to us today regarding your question.
So that we can best help, would you be able to provide a bit more detail in what you are trying to achieve?
Kind Regards,
Dom.
We often deploy applications to all servers in parallel. I think the maximum by default is 8 or so. So we added the project variable to allow up to 24 to be deployed to at once. This saves us alot of time on product release nights.
At other times when we want to say cycle an application service without impacting a customer. We want to use a rolling deployment to cycle that service one server at a time. The rolling deployment set to a maximum of one does not work due to the project variable being set to max of 24. That breaks rolling deployments.
I need to be able to do both. Deploy to a maximum 24 when needed and deploy rolling with a lower setting then the max of 24.
I personally am surprised its not the other way around with the most restricted step level variable overriding the high level least restrictive.
Octopus Max parrallesim.docx (346.0 KB)
Hi @brian.cooperider,
Just stepping in for Dom while he’s offline, cheers for that extra info!
I believe there’s actually a bug here as the context we provide about this behaviour in our docs for Configuring a Rolling Deployment seems to be the opposite of what you are experiencing:
Window size with Octopus.Action.MaxParallelism
If you include the variable Octopus.Action.MaxParallelism in your Project with a value higher than your Window size set in a rolling deployment, you will find the Octopus.Action.MaxParallelism value is no longer respected. This is expected behavior as Octopus also uses this variable to limit the number of deployment targets on which the rolling deployment step will run concurrently. A warning will also be printed in the Task Log.
And our docs about System Variables also indicate that Octopus.Acquire.MaxParallelism is the same variable defined in the Step Template’s WindowSize which explains the warning in shown when using it with a Rolling Deployment:
The maximum number of deployment targets on which the action will concurrently execute, and the maximum number of steps which will run in parallel. This value can be set in a project variable to change the default for the project. Additionally you can scope a value to specific actions to control concurrency across your deployment targets. This is the same variable which is set when configuring a rolling deployment. (Number - Default: 10)
Note: Some built-in steps have their own concurrent limit and will ignore this value if set.
I believe a possible workaround could be to use a Child Step for the Rolling Deployment which doesn’t have the Octopus.Acquire.MaxParallelism variable set and so should use the WindowSize instead.
I’ll dig into this and see if I can spot exactly what’s going on and keep you posted with any suggestions but feel free to reach out with any questions in the meantime!
Best Regards,
Hi @brian.cooperider,
Just an update that the devs have confirmed this is a bug and have created the following Github issue for tracking it’s resolution: WindowSize is not being respected when Octopus.Action.MaxParallelism set to a higher value · Issue #8170 · OctopusDeploy/Issues · GitHub
Feel free to let us know if there’s any issues with the suggested Child Step workaround or you have any questions at all, thanks heaps for pointing this out to us!
Best Regards,
1 Like
Thanks, I’ll try that out and see what happens.
2 Likes
Hi again,
So I was trying to set this up this morning. In the documentation it shows the process having other steps prior to creating the child step as a rolling deployment. My process currently only has the one step which is configured as the rolling deployment and contains all steps. The only difference I see from my runbook and the one in the documentation is that it includes prior steps that are independent.
Hi @brian.cooperider,
Sorry I could have clarified the suggested workaround better, however it looks like I was meaning to suggest using a Parent Project instead of a Child Step in a Rolling Deployment!
The idea is to create another project for the Rolling Deployment Step that doesn’t use Octopus.Action.MaxParallelism as a Project Variable, so the WindowSize variable set on the Step should be respected.
Parent Project - Uses Octopus.Action.MaxParallelism project variable and the built-in Step Deploy a Release Step
Hope that helps but feel free to let me know if you have any questions at all!
Best Regards
OK, I see how that would work. Don’t like the idea of having to create a separate project for rolling deployments but it does solve the issue for now. Thanks for all your help.
1 Like
Hey @brian.cooperider,
Just stepping in for Finnian whilst he is offline as part of our Australian based team, its great news that the workaround would work for you. I am sorry it is a bit time consuming setting it up but it is just a workaround to get you unstuck for now.
Hopefully we can get to implementing a more permanent fix since Finnian did create a GitHub issue for it so as long as you subscribe to that GitHub issue you will be notified when the fix is out.
Reach out if you are struggling to configure the workaround and we will see how we can help.
Kind Regards,
Clare
1 Like
Hi again,
OK, I know I’m missing something really stupid. I have created projects in the past and likely resolved this issue in the past. After creating the project and cloning the runbook from the other project I’m having an issue. If I run the runbook I get no deployment targets found. I have connected the required tenants to the project.
octoproject.docx (552.4 KB)
Hi @brian.cooperider,
No problem at all, cheers for providing the images of your setup! I think I’ve misunderstood your exact issue with my previous suggestions but now can see what’s going on.
The warning is indicating that there aren’t any Deployment Targets which use those tags, in that environment, that are enabled. I can see there are some disabled targets, are those tags included in the 8 disabled targets?
Otherwise everything looks like it should ok, looking forward to hearing how you get on!
Best Regards,
Hi,
None of the targets included in those tags are disabled. That run book is still running in the other project without issue. I think everything looks good as well, which is why I can’t figure out why its saying theres no available targets.
OK so just for grins I thought. I manually duplicated the runbook. The new runbook has no issues finding the targets. I don’t get it but I guess as long as the new one works I’m good for now. Weird if you can explain please do, otherwise we will just add it to the library of Strange and the Weird in the land of IT.
I solved the mystery. The run settings had “Runbook cannot be run against a tenant” . Duh ! I didn’t even catch that I wasn’t able to select a tenant when trying to run it.
You all have a good week!
Hey @brian.cooperider,
Great news you managed to solve this, things like that are easy to miss if you have been clicking around in a piece of software and have been changing a few things to get something to work, its easy to miss a radio button or some tick box, then you end up kicking yourself once you figure out which tick box you missed!
So I totally get it, plus, as you mentioned, sometimes IT fixes do not make sense so you do have to move on and point it to some kind of wizardry that has occurred!
If you need anything else please do reach out as we love to tackle challenges with our customers, especially ones like yourself who are really helpful and do their own testing to!
Kind Regards,
Clare
1 Like
