vRA 8.7 - ABX 'new On Prem engine' causing 'argument list too long' error

[BrettK1]

I have a powershell ABX action that worked fine in 8.6.  After upgrading to 8.7, it now fails with the following:

Log: standard_init_linux.go:228: exec user process caused: argument list too long

Trace: Retrying action due to error state 'FAILED' in previous run attempt: Action run failed and it was not possible to extract error message

AFAIK only the vRA version (and therefore ABX engine) changed.  Any ides of where to even being troubleshooting this?

[BrettK1]

For testing purposes, I created a new ABX action that fires Compute post provision.

The action is the default powershell script (Write-host "hello " $inputs.target, return $inputs) with zero modifications.

It fails with the same "standard_init_linux.go:228: exec user process caused: argument list too long", so at least my script isn't the issue...  interesting...

[sakkimuhammad]

Have you got any fix ? I am also getting same error.

[BrettK1]

Negative, I have an SR open for this, but haven't made much progress on an overall answer.
I have one old Powershell ABX that runs fine, and 2 others that run fine ONLY IF that first one isn't run first.
None of the Powershell ABX actions modify the vRA deployment at all (they only run some powershell commands locally on the deployed VM).

[BrettK1]

Something I just noticed is that the first ABX Powershell that I run has about 90 lines of input, and for some reason about 9,600 lines of OUTPUT.  The next ABX that tries to run takes all those in and has 9,700 lines of input, and crashes.

Looking at runs prior to the 8.7 upgrade, this was also happening then, but the scripts still ran anyway.

I have no idea why there is so much output generated.  It is all vCenter / EVC info (as if there is a Debug mode turned on)

[xian_]

https://docs.vmware.com/en/vRealize-Automation/8.7/rn/vmware-vrealize-automation-87-release-notes/in... writes the new engine logs consumed memory but does not explain the behavior you described.

[Ankush11s]

We are aware  about this 
This will get fixed in next release which is 8.8 expected to release soon.

Problem Statement:
Currently this issue will happen if we are returning more properties , in your case it is 9200 which is huge.

Background about issue:
Let assume we have abx action flow which will consist 3 actions.
If we are returning 100 hundreds of properties  in return of First action ,those properties will be available as input of 2nd actions which is causing this ,or if you do not have abx flow just an action which is returning huge number of properties.

As workaround: 
Please check which action is returning huge number of properties and if possible make it precise to only required fields

example:
If we return entire $inputs this will consist n number of things , we would suggest you to return only required properties as workaround
example...
$output = $input['result']
return $output
In upcoming release this will be fixed .

Let us know if you have any questions.

[BrettK1]

The odd thing in my case is the ABX action has no outputs (that I'm aware of), and therefore I don't know why it sending 10K lines of output to be ingested by the next action.  All the lines appear to be vCenter settings and hardware info, nothing that I am attempting to collect (or even know how off the top of my head).

[Ankush11s]

Can you post your abx action if possible ?

[BrettK1]

Ankush11s proposed 2 solutions to my version of the problem, EITHER of which fixed it, both of which are probably best.

1) Set the connect-viserver command to a variable.
i.e. $foo-bar = connect-viserver blablabla

2) return $inputs (or something else)
Since I didn't want my function to actually return anything, I had no 'return' statement, so apparently it decided to return whatever it wanted to.

[Ankush11s · Accepted solution]

PowerCli or Powershell are covered under Polyglot languages in vRA/vRO.
so we follow strict guidelines of Powershell Core and Docker . Since these languages run their code in docker , Any command in PowerCli/Powershell which produce output to screen will give problem 

As Best Practice we recommend our customer to provide the variable to all the commands 
Also on Return It is recommended from programming perspective to always specify what do we really want to return to avoid unexpected return outcomes .



Please mark the thread as resolved if your issue is fixed

[BrettK1]

Thanks, these are good to know.  Given I (and probably many other vRA/vRO users) am not a programmer, these 'best practices' are well beyond our normal scope.

"Any command in PowerCli/Powershell which produce output to screen will give problem"  - Thanks, good to know.  I had luckily had all other commands set to a variable for actual parsing, etc, so only the connection string caused an issue.

"Also on Return It is recommended from programming perspective to always specify what do we really want to return to avoid unexpected return outcomes ."  - As a note, I wanted 'no return', but setting 'return $null' causes an error.

Thanks!

[gradinka]

this should be resolved in vRA 88 which is coming out shortly