Worker target summary missing with parent / child steps

usability
(mike) #1

Hi,

I’ve recently started provisioning a new worker pool with a new worker in it running as an Azure VM with an Octopus Tentacle configured to be a worker (using “tentacle.exe register-worker”) to improve the deployment performance of some Azure-based steps. The idea is that running the scripts in an Azure VM-based worker means things will run at local Azure network speed rather than over our (slow / unreliable) ExpressRoute connection.

I think I’ve got everything more or less working and it seems to deploy ok, but I’m having some problems reading the UI for my process where it has child deployment steps - I can’t see where the worker config is defined in either the parent or child steps.

My two original steps looked like this:


When I added My Step 2 as a child step of My Step 1 the UI lost some of the information - what I see in each step is this:



Neither the parent nor child steps mention the “SI Worker Pool” once they’re nested, which makes it really hard to see what the deployment process will actually do.

Am I not looking in the right place, or is this information just not shown in nested steps? We’re on Octopus Deploy version “v2018.1.0.0 LTS” so I guess it’s possibly already been changed in a later version.

Cheers,

Mike

(mike) #2

By the way, when I query the API for this project I see “WorkerPoolId”: “WorkerPools-21” in both child steps, so the information is there - it’s just not shown in the UI. Also, the deployment does actually do the right thing as well, so I think this primarily is a UI issue.

Cheers,

M

(mike) #4

It looks like this is at least partially fixed in the latest version of Octopus (v2019.6.3 at the moment). The UI now shows the Worker Pool name in child steps, but I’m still not sure the “Run once” option is fully represented:

There’s no “Run once” radio button, and the text at the bottom of the image leaves a dangling “each deployment target in the following roles:” message with no following roles (because I’ve not assigned any).

(Michael Richardson) #5

Hey Mike,

I can see why this seems strange, and we can quite possibly do better here.

The reason you aren’t seeing the “Run once” option is that it is not presented for child steps. Child steps are designed for modeling rolling deployments. Though in your case you’ve selected Deploy to all deployment targets in parallel which is essentially a rolling deployment with a window size equal to the number of targets.

In these scenarios, run once isn’t a valid option, as the child step will run once for each target matching the role of the parent.

Does that make sense? What are you hoping to achieve with child steps in your scenario? Is it just for grouping, or did you have a specific deployment plan in mind?

(mike) #6

Hello,

So I’ve actually got a pattern of sets of 4 steps in my deployment - something like below. The child steps are more for logical grouping than for rolling deployments:

  • 1 Deploy Azure WebApp A

    • 1.1 Create “staging” deployment slot
    • 1.2 Deploy Azure Web App to “staging” slot
    • 1.3 Swap “staging” deployment slot
    • 1.4 Remove “staging” deployment slot
  • 2 Deploy Azure WebApp B

    • 2.1 Create “staging” deployment slot
    • 2.2 Deploy Azure Web App to "staging slot
    • 2.3 Swap “staging” deployment slot
    • 2.4 Remove “staging” deployment slot

I’m using the “Legacy” mode for the WebApp deployment so we’re licensed by Worker rather than per App Service, and the other 3 steps are custom Azure PowerShell step templates I’ve written myself.

(There’s a couple of dozen projects like this - I’m eagerly waiting for Composite Step Templates so I can refactor them all :slight_smile:)

At present we’re deploying using “Run once on octopus server” to Azure over our ExpressRoute connection which is a somewhat glitchy and fails often enough to be a bit of a pain - probably more due to our internal network configuration than anything else.

What I’m trying to do is provision an Azure VM with the tentacle service installed and configured as a Worker in a new Worker Pool so that the more reliable Octopus “package acquisition” is performed over the flakey connection to Azure, and then the Worker can do a high-speed Azure-to-Azure deployment of the App Service - from a technical perspective, I’ve got this all working, it’s just that the UI doesn’t make it clear what it’s configured to be doing, and I’m worried I’d be handing over a plate of cryptic spaghetti to our devs if I leave it like is currently is.

I found it’s been improved in the latest version (v2019.6.3) so it now shows the Worker Pool in the child step page, but the whole run once thing isn’t very clear - I originally configured the separate steps as “Run once on a worker” and then when I moved them into a parent step it automatically turned into a “Deploy to all targets in parallel”. If I separate the steps again they go back to “Run once” so it looks like the internal data is how I want it to be - it’s just not surfaced up to the UI.

Could you suggest how to configure the Workers, Roles, Steps, etc, to achieve what I want - i.e. "run once on an Azure-based Worker in my “SI Worker Pool”?

Cheers,

M

(mike) #7

I just noticed something in the last image I posted - the graphic on the right of the page in the “Execution Location” section shows the “Execute once on a worker” image, so it’s almost like the problem is that the “Run once on a worker” radio button is incorrectly hidden / omitted in the dialog in child steps, but it’s still the “active” option.

(Michael Richardson) #8

Ahh, thank you for the additional information. I better understand your scenario now.

The truth is, you’ve slipped through the cracks in the logic somewhat.
As I mentioned, child steps are designed for modeling rolling deployments. Octopus doesn’t allow child steps to be added to parent steps which “run once”. But by using the ‘Legacy’ mode for the Azure Web App step, the UI has allowed you to configure child steps for a “run once” parent.

That’s why the UI behavior is odd; it’s a scenario it isn’t expecting.

I’m going to chat with our team about your scenario, and I’ll get back to you with a decision of either:

  • this is a valid scenario (and we’ll fix the glitch)
  • this isn’t a recommended use of child steps, and we’ll suggest for you to flatten them

Using an Azure VM in a worker pool sounds like a nice approach.

Something to consider as an alternative way to model the deployment process:
You could possibly collapse the four steps into a single Deploy an Azure Web App step and configure the Custom Deployment Scripts feature. Creating the slot could then be done in the pre-deployment script, while swapping and removing could be done in the post-deployment script. This would also possibly allow you to model the whole process as a single step template.

Would this work?

(mike) #9

Hi Michael,

Thanks for the update. I drifted toward the child steps approach for a couple of reasons:

  • Sometimes we don’t want to swap the slots - maybe we’re just doing a deployment into the “staging” slot to compare configs or smoke-testing in the LIVE web app before we launch the new version to customers a few days later, so having separate steps means we can just execute the “Reset staging slot” and “Deploy to staging slot” steps and disable the “Swap staging slot” and “Remove staging slot” steps in any given deployment

  • The logical grouping means it’s easier to set up and maintain (although it sounds like that’s not what parent / child steps were originally meant for, so maybe I’m trying to crowbar behaviour where it’s not supposed to be!). One of our projects, for example, is made up of 5 web apps, and having a flat list of 20 steps would make it hard to “see” the 5 separate web apps in the process.

I’ll wait to hear back from your team, but for what it’s worth I think it’s important to have some way to logically group related steps in long processes for maintainability and usability, but like you say, the parent / child layout at the moment is coupled with managing rolling deployments so it has some additional behaviour than just partitioning steps…

Cheers,

M

(mike) #10

@Michael_Richardson - have you heard anything back from your team re the approach I’ve taken for my WebApp deployments in terms of whether it’s “supported” or not?

Cheers,

M