The log file will give me a contextual idea of what is happening during your deployment and what could be going wrong.

My current assumption is that your deployment is still running at 10 tasks in parallel instead of 6. Is this correct?

Are you able to confirm that you created a new release after adding this variable? Any variables are associated with a release, so new variables will need a new release to be picked up in your deployment.

Thanks for getting back with the variable logs. Though it think I know whats going on here. I may have initially misinterpreted your issue, the Octopus.Aciton.MaxParallelism variable is responsible for how many machines/targets each step will run on in parallel. It looks like you are trying to specify how many deployment steps should be executed by octopus in parallel.

To configure this, you will need to put your steps into child steps. This have Octopus run the child steps in batches.

The documentation I linked to has a lot more information on this.

Let me know if you have any thoughts here, or if I have misinterpreted your issue still.

That’s a pity, I was hoping to use MaxParallelism to make my deployments more elastic.
Now we are running multiple deployment steps in batches 6 in parallel then next 6 are waiting for first one set to finish and that same for next series. Now we have 36 deployment steps and those steps deployment time is different at each execution(it is related to the jobe executed by particular msvc, sometimes we have to wait before shutting it down). So sometimes entire series will update smoothly and sometimes we have to wait for single msvc to finish his upgrade before starting next one, and that causes more or less 2h upgrade of single zone.
I was hoping that there could be some kind of queue from which octopus will take only 6 steps and when any of that steps will be finish then he will grab next one. I don’t think that I will be able to achieve that with child steps.