Hi, I would just like to report that I have found that the task details of my deployment are very misleading
I have a deployment process that uses a tentacle. The system has steps that run both on the tentacle and octopus server. However I get confusing details in the log (see attached) The items with a red box around them run on the octopus server, while the back box items run on tactical. But you will notice that in step 3 I have both black and red boxes under the Australia VM! (my tentacle)
What I would like to see / expect to see is all red box items under the header Octopus server and all black box items under headers Australia VM. (As seen in the step before the database deployment)
This current output gives the very false impression that processes are running under the Australia VM when they are actually running locally on the octopus server.
I have also attached screen grabs of my processes so that you can see that they are set to run on octopus or targets / tentacles
Thank you for getting in touch. It looks like you have setup the database steps as a child steps. Child steps run once in sequence for a deployment target with an optional window size. The primary use of child steps is for rolling deployment deployments, rather than logical grouping.
This is why the steps have been grouped under the machine itself, those steps are all running under the context of that particular machine. Although the title could be clearer, if I remember correctly one of the first lines of the log should say where it runs.
I assume you only ever want to run the database steps once, and not once per database machine. If so, I recommend not putting those steps in as child steps, rather as top level steps.
I could move my steps, and that would be fine for me, but the problem will still exist in Octopus. The task details are misleading. And if in the future I had a legitimate child step then I would have exactly the same problem. The fact that child steps can be run using the server or a tentacle suggests that it would be shown in this output correctly.
It is a shame as up until now we have been using this screen to keep an eye on the deployment as it has excellent usability and responsiveness.
My work around will be not to use a tentacle at all rather than moving child steps. Having child steps offer more advantages (grouping, batch enable disable and readability) where as the tentacles use is surprisingly limited as almost all azure related steps must run from the octopus server. (Something that was not noticed until recently as the task output shows the steps as running on tentacle VM)
Thanks again for your response, and I hope that this problem gets resolved in the future and Octopus is an amazing product overall.
The first attachment shows the process
My grouping for this part is “database stuff” containing 3 parts
Check and create a server if none exists
Create / update the databases
Make sure all the databases are in the elastic pool
This works well for me as its all nicely grouped together and I am easily able to see how long the database part took and I can disable database deployments with ease. plus other steps that require the database can correctly wait for this to be completed before continuing. So I have no problem with how this works.
But step 3.1 and 3.3 acutely run on the octopus server, and step 3.2 runs on the tentacle.
And that makes it look like all the steps ran in Australia when 2 of the 3 did not have anything to do with that tentacle and actually just ran on the local server (in New Zealand)
What I would like to see is this (Hand crafted UI, NOT A REAL SCREEN GRAB)
This would show me where my things are running, And this is exactly what we were expecting to see since some other steps do show like this.
In short the header should come of the actual step that’s executing NOT the parent step as that could be in a totally different place.
Yes I can see where you are coming from and we’ll take that on board.
The other thing we need to consider is that the grouping represents each machine in a rolling step. For example if we have the process:
Deploy Website
Take out of load balancer (run-on-server)
Deploy Website (run-on-target)
Add back to load balancer (run-on-server)
And if we have two machines, currently the log will look like this:
Deploy Website
Machine 1
Take out of load balancer (Success)
Deploy Website (Failed)
Add back to load balancer (Not Run)
Machine 2
Take out of load balancer (Success)
Deploy Website (Success)
Add back to load balancer (Success)
The Machine 1 and Machine 2 steps run in parallel (if the window size >= 2). In this case it is important to know which machine the “Take out of load balancer” step ran for.
I hope that explains why it is structured in the way it is.
This way I can see everything I want, plus this method would work in the case that I have where I only have the one machine,
Just for some more background as to why it is so important:
We have a number of VMs around the word. When there are problems we need support staff to be able to find the problem and fix it. This could be bugs or general speed of deployment. The problem came as support where trying to improve the tentacle (VM) to help improve performance but this had no effect. And this we due to the step actually running on the octopus server and not the tentacle at all (as the top level output suggest)
The (On Octopus Server) could work, or an icon of the octopus / tentacle would also work. Anything that gives a clue where the process is running.
The performance is well known now and it relates to the fact that we have servers all over the world. This means that the roundtrip time can be very time-consuming. The idea it seams was to run the steps on tentacles that where in the same geographic location. This appeared to work as the screen suggested that all the things we wanted to run were now running in the appropriate countries.
As it turned out… that was not true.
The upcoming worker seems interesting, I will definitely take a closer look over the next few days. However for me (apart from the UI issue) what we need is the ability to run all the steps from tentacles.
in particular the azure PowerShell step. But that’s another issue…
