Estimated reading time: 5 minutes
After upgrading Aria Automation from version 8.16.1 to 8.16.2, our team encountered a critical issue: ABX Actions written in Python began to fail during execution. Review of output logs revealed an unusual message, suggesting a disconnect between Python runtime environments post-upgrade – despite the user interface displaying the correct environment. This post details the symptoms we observed and the temporary fixes we’ve implemented, in anticipation of an official bug acknowledgment and solution from VMware.
Symptoms
- When a given ABX Action written in Python is executed, the Action Run will fail.
- Deployments dependent on ABX Actions will fail.
- After opening a failed Action Run and clicking on the “Log” tab to review the output, the final line reads, “Runtime python with version 3.7 is not valid for provider on-prem”.
- Despite the above error, the selected Python runtime environment is “Python 3.10”.
Work Around Measures
Pending investigation by VMware Support and confirmation on whether this is classified as a bug, we have outlined a couple of interim solutions:
Option One
- Launch Aria Automation Assembler, then click on the “Extensibility” button, located along the top ribbon.
- Locate and click on a Python-based ABX Action which has been impacted by the above symptoms.
- Locate the “FaaS provider” drop-down menu, located to the right-side of the window. Click on the drop-down menu, then click on the “Auto Select” menu item. Click on the “Save” button, located at the bottom-left of the window.
- Once again, click on the “FaaS provider” drop-down menu, then click on the “On Prem” menu item. Click on the “Save” button.
- Perform validation to measure success. It may be necessary to launch a test deployment, depending on the intended function of the ABX Action. If the action still fails with the same log message as described in the “Symptoms” section above, proceed to work around Option Two below.
Option Two
- Launch Aria Automation Assembler, then click on the “Extensibility” button, located along the top ribbon.
- If possible, duplicate this browser tab. Alternatively, it is recommended to open a separate browser tab or window and navigate to the same page.
- In the first browser tab, click on the ABX Action which is failing due to the described “Symptoms” above.
- Click on the “Settings” button, located to the right of the Action Title.
- Click inside the “Name” field and modify slightly to indicate that this action is the original/former/nonfunctional instance. My preference is to append “zzz” as a prefix, but the choice is yours and will not impact future steps.
- Click on the “Apply” button to close the “Edit Action” window, then click on the “Save” button, located at the bottom-left corner of the window. Keep this page open for reference.
- On the second browser tab or window, click on the “New” button located beneath the “Actions” heading.
- Inside the “Name” field, copy the Action Name (without the “zzz” prefix described above) and paste into the “New Action” window. Ensure you scope the same “Project” and if appropriate, tick the “Share with all projects in this organization” checkbox. Once satisfied, click on the “Next” button.
- A blank ABX Action Template will launch. Ensure the runtime environment, located to the top-left of the script editor pane, has “Python 3.10” selected.
- Copy and paste the Python code from your original ABX Action in the first browser tab/window to this new (blank) ABX Action.
- Ensure the following elements are configured identical to the original ABX Action:
- Main function
- Dependency
- FaaS Provider
- Once the code and all attributes are configured identically to the original/reference ABX Action, click on the “Save” button.
- If the ABX Action is executed directly by a Subscription, you must modify the Subscription and click on the “Change” button, located beneath the “Action/workflow” heading, and select the new ABX Action you just created, else the original ABX Action will continue to execute when the Subscription fires.
- If the ABX Action is executed as part of a Flow, you must open the Flow (located in Extensibility > Actions), select all of the code located in the code pane, copy to your clipboard, delete/clear the code pane, then paste the code back into the code pane, and click on the “Save” button, located at the bottom-left corner of the window. Although the literal text in the code pane is the same, removing and adding the code back will force Aria Automation to resolve the Action Names to back-end identifiers once again, else the Flow will continue to reference the original/reference ABX Action. I realize this work around is not elegant, but it has proven effective in our environment.
Wrapping-Up
While upgrades inherently come bundled with potential risks to operations, this scenario is a classic example. My team has escalated this issue to VMware Support for a closer look and possible Engineering intervention. Should a formal resolution emerge, I plan to update this post and publish a follow-up for broader awareness. Prior to considering an upgrade for any software platform, it is highly recommended to read over the Release Notes, particularly the “Known Issues” section, before proceeding. Given that Release Notes are continually refreshed, a final review just before an upgrade can help catch any new details that may have been added since your last check.