VMware Cloud Community
omrsafetyo
Enthusiast
Enthusiast

VRO workflow element order messed up

Is there any way to correct the element order in a workflow?  I have seen some really bizarre behavior.

I have a workflow that will resize a VMDK, and then go into the OS and resize the disk as well.  This has worked in the past using a "Run command in guest" command, I just set up a powershell script, and then execute the script as a scriptblock parameter to powershell.exe as the program.  But, with UAC, this wasn't working so well, and I couldn't get Powershell to elevate for me.  So I switched to using a PowershellHost, and running the script as an external command

When I did this, I had done some testing by building a new workflow, testing the OS layer disk extension there, and then when I was happy with it, I copied the elements into the existing workflow, removed the run program in guest pieces, and dragged these into place, updated parameters, etc.  I thought it would work, but it started doing some weird looping.  It would get to the first element that I had newly copied in, and then it would start the workflow back over from the beginning.   I looked at everything closely, and couldn't find an issue.

Eventually, I found that if I went into version history, and did a "diff against current version" from an older version, I would see that the success path of this element led back to the first step in the workflow.  That wasn't how it showed on the schema pane, and if I selected the element, the "next step" was the step I expected.

I ended up reverting to that version, and when I did, the messed up workflow showed up on the schema pane as well, so I was able to fix it.  But I still had problems - now the workflow won't run at all. 

I selected the "start workflow" element in the schema pane, and looked at the ID column.  I found that the last step in the workflow (the End step) was marked as item0.  It seems that this step being item0, despite that it was at the end of the workflow, and not the beginning, was causing it to use the end of the script as an entry point.  I created a new end step, re-pointed everything and deleted the existing one.  But examining the ID column, the first step was still showing as item3, with two items that come some time after it showing as items 1 and 2.  I deleted and recreated those steps - and now my first element is item3, and still my lowest numbered item - but when I run the workflow, its like nothing happens.  I really don't understand why this is.

I'm wondering if anyone knows a way of re-ordering the workflow items to ensure appropriate flow.
Thanks

Reply
0 Kudos
5 Replies
qc4vmware
Virtuoso
Virtuoso

The item number should not be affecting the flow.  I think the end item is typically item0.  Items are numbered in the order they are added to a workflow to the best of my knowledge.  Can you upload the workflow for examination?

Reply
0 Kudos
iiliev
VMware Employee
VMware Employee

These numbers do not have ordering semantic. Their purpose is to ensure that every workflow item within a given workflow has an unique ID in order to describe the transitions between workflow items as directed graph links; that is, workflow metadata contains a bunch of records like 'there is a transition from itemX to itemY on success' or 'there is a transition from itemY to itemZ on failure'.

In general, you should not make any assumptions about these numbers - they can start from a number different than 0, there is no guarantee that the numbers are generated sequentially (there can be gaps), etc.

Reply
0 Kudos
omrsafetyo
Enthusiast
Enthusiast

Hello,

Thank you both for your answers.  I made some assumptions that ended up being incorrect.

So firstly, the initial issue was described:

I thought it would work, but it started doing some weird looping.  It would get to the first element that I had newly copied in, and then it would start the workflow back over from the beginning.   I looked at everything closely, and couldn't find an issue.

Eventually, I found that if I went into version history, and did a "diff against current version" from an older version, I would see that the success path of this element led back to the first step in the workflow.  That wasn't how it showed on the schema pane, and if I selected the element, the "next step" was the step I expected.

So,  lets say I have item3, which is the first step in the workflow.  I also have elements item9, which is a Scriptable Task which sets up some variables, and item22 which is the Powershell built-in workflow, Invoke An Extenal Script.  For the success path (normal workflow progression) on item9, it moved to item22.  There was no error path.  However, after this step was finishing, and the System.log() items that I had coded into this script were outputting in the Logs pane, I would see it output information from item3.  There was no path from item9 to item3, so I couldn't figure out what was going on - I was never getting output from item22 and if left alone, the workflow would loop forever.  When I looked at the workflow from the version history diff screen, I could see that the success path was going from item9 to item3, which is not how it was showing in the Schema pane.

Coupled with that, it seems like my System.log() calls have stopped working.  I fixed the workflow, by reverting, and then correcting the incorrect normal workflow progression path.  But, since I've done that, there is currently nothing outputting to the Logs pane.  So when I was executing a workflow, I wasn't seeing any output - I also was not able to watch the workflow progress for whatever reason.  So I would see the workflow finish without logging anything, and seemingly without doing anything (it turns out I had an error, but I couldn't see it).  So to me, it seemed this meant it was only executing the end-step of the workflow, which I noticed was item0.  This is what led to my confusion

I now have this corrected and working, as once I realized my workflow was in fact executing, I was able to determine why and correct the issue.  This doesn't explain the initial issue - which is that the workflow actually had an incorrect normal workflow progression from item9 to item3, even though it showed as item9 to item22 in the Schema pane of the workflow - but I was able to figure that out from the diff screen in the version history - so note to anyone else, it might be worth looking at your schema pane in the version history diff screen if you are encountering similar issues.

Thank you for your help.

Reply
0 Kudos
qc4vmware
Virtuoso
Virtuoso

It sounds like you have an active path that you may not have seen in the designer.  I've had cases where both the failure and success paths are pointing at the same next step but its not easy to tell from the way things get drawn in the gui.  I'd suggest simply removing the connections and reconnecting in the correct order.  I've never encountered a workflow that wasn't actually following the path that was created although its possible you came across a bug of some sort.

Remember when viewing the logs you can set a filter for different log levels.  Make sure you haven't accidentally filtered out what you are expecting to see.  If its debug level logs that aren't showing there is a known bug where you may need to modify a config file to get debug logs showing again in the orchestrator client.  I forget the version where the bug appears but if you search on that you'll get a kb article.

Paul

Reply
0 Kudos
omrsafetyo
Enthusiast
Enthusiast

I don't believe the case is that I have it filtered out.

Reason being, if I select a given workflow from the list, and view the completed and current workflow runs, anything older than the time this occurred has the full logs displayed.  I have a few executions that are currently paused waiting for an execution date, and they have a log entry:

[2018-05-13 07:21:20.340] [I] Current time (Sun May 13 2018 07:21:20 GMT-0400 (EDT)) is before the action date (Fri May 18 2018 03:00:00 GMT-0400 (EDT)).

I then have the 2 most recently executed workflows, one of which is sitting in the same wait state for the same reason, and they both display:

No logs found

Once I noticed this behavior in the other workflow, I've noticed that no workflows on this VRO instance are logging anything new (though, I will have to wait for the 3 currently paused workflows to resume execution to see if they will log anything - 2 of the 3 have the log about the action date - so I'm curious to see if those runs continue logging, or if they record no new actions).  But I can still review any previously logged logs.  Events, logged with Server.log are logging fine, it's just the System.log logs that are not displaying.  This includes any exceptions that should have been logged there.  Though, if I go to the Variables tab, I can see all the logs that have been set, and I can get the Exception stack from there (this is how I resolved my other issue).

But no workflows on this Vro instance seem to be logging anything to the log related to System.log

From this thread: VRO Log Messages 

The amount of logs stored in log files is configured through file /etc/vco/app-server/log4j.xml . Most of the log files (eg. the main one - server.log) are managed by a rolling file appender, which means you can configure the maximum log file size and the number of backup index copies. So when the amount of data output to a given log file exceeds the max file size, a backup copy will be created and the following log data will go a new file, until the max number of copies is reached, and when this happens, the oldest index file will be deleted.

So it seems like I may have hit a logical limit, and the roll over is not occurring, or something similar (I have not investigated this yet)

Reply
0 Kudos