I have a task that deletes a VM from a CMDB when the VM is removed. But I am trying to figure out how, forensically and after the fact, I can go back and visually see the output of that task run. Activity doesn’t seem to have this information.
There is a log, but it gets automatically pruned.
With that said, you’d probably be interested in 6.0.5 and 6.2.0. In both of those releases, we will be stopping on failure during teardown (unless a force deletion is used). This will allow you to decern issues and retry teardown.
I just upgraded everthing to 6.1.1 (last environment done today actually). This comment you made about Teardown and whether to stop or not - gets into a topic of increasing the sophistication of the workflows. I think all tasks in a Workflow should have some kind of a “continue workflow on task failure” flag or something. but, given that you can run a task by itself, and not just within the context of a workflow, i don’t know how you would design and implement that off the top of my head.
But I remember trying to shuffle the tasks in a workflow like cards in a card deck, to try and get some more important tasks run before the more fragile (likely to fail) tasks ran. For example, my last step was to “lock down” the virtual machine with security settings. And this would never run if an upstream task failed. But, if you move the “lock it down” task to the front, then you can’t run the other tasks (due to the lockdown itself). It was a chicken or egg kind of thing which really, I have not solved even now.
In the works! Just was not ready for 6.2.0
But @cbunge we also need a way to, via the Morpheus UI, inspect the results of a workflow run prior to the VM being torn down! There could be an important task being done, that if we don’t know it failed, could result in some issues.
Would this be different than the 6.0.5 and 6.2.0 introduction of stopping a teardown of asystem if a task in the teardown fails? (I would have to make one manually fail to see what all gets presented).
Maybe a little different. Maybe the task is not set up to specifically fail. Maybe it is a long transaction of things, and most of them run ok but the last step which is not as important fails. I don’t really have a good way to know what happened if the VM was completely vaporized and the trail disappears. I think a Workflow History would be a good thing, even if the VM is in the process of being torn down.