Support child steps that run on roles/machines other than the rest of the rolling step

[PaulStovell]

Scenario: http://octopus-deploy.tenderapp.com/discussions/problems/15836-powershell-child-step-cannot-be-executed-on-octopus-server

Perhaps an alternative would be, when configuring a PowerShell step as a child action, you can choose whether it should be executed on the "current machine" in the rolling deployment, or a single machine in a specific role.

[PaulStovell]

D'oh, referenced the wrong issue in my commit. This one is not fixed.

[PaulStovell]

Another vote for this via email. Scenario is: machines need to be removed from F5 load balancer, but the machines don't have access to the LB for security reasons.

[dave-sansum]

+1 This is a blocker for us now and none of the workaround soutions are really feasible.

[michael-huxtable]

Is this coming in 2.6? How can we access information about the machine that the child step is running on if we run a specific step on another machine?

Specifically when considering the load balancer scenario if a step runs on the deploy server rather than the child step machine we would need some child step context information such as the current IP / network information of the machine.

Otherwise when the step runs on the deploy machine we won't be know what server to remove from the load balancer 😄

[DamianMac]

Will add ability to run scripts from Octopus Server which will solve these scenarios

[repler]

Is there any update on this?

[PaulStovell]

Here's what we will do:

1. You can add PowerShell script steps that run on the Octopus server. If they are part of a rolling step, they still run on Octopus server but are passed variables related to the current machine in the rolling deployment.
2. You can also add manual steps. These won't persist the deployment (it stays executing in memory, just in a wait loop).

Whoever picks this up, might be worth chatting to me first.

[robpearson]

Release Note: Email, Manual Steps and Azure Powershell steps can now be executed in a rolling step. Also added support to run a PowerShell Script on the Octopus Server.

[hansenfreddy]

When you say "Run on the Octopus server" - this means that we still e.g. can't execute powershell on a tentacle on the load balancer in a rolling deployment?

See: http://help.octopusdeploy.com/discussions/questions/6653-cannot-utilize-tentacle-on-load-balancer-need-to-remote-execute-powershell

So this means we still would have to talk to the load balancer remotely (remote execute powershell for example) from the Octopus server?

[PaulStovell]

That's right - with this change, steps in the rolling deployment either run in the Tentacle in that rolling deployment (e.g., the web server), or now the Octopus server. They can't run on some other random Tentacle yet.

[cainux]

I am currently in a scenario where I need this exact feature. We have a couple of load balancers (primary and backup) in front of our application and would like to be able to remove nodes from them both during a rolling deployment.

Our web servers and load balancers are connected to Octopus and have their own roles (web, loadbalancer).

The process looks like this:

1. Determine deployment targets (web)
2. Disable deployment targets on the load balancers
3. Deploy package (web)
4. Enable deployment target on the load balancers

Right now our workaround is to manually pick the deployment targets and run the deployment twice (we only have 2 web nodes right now).

Looking at the history of this though have people come up with a better way/workaround?

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you think you've found a related issue, please contact our support team so we can triage your issue, and make sure it's handled appropriately.