Hi Milosz,
Thank you for your response and suggestions!
I have a quick clarification question about the interactive shell approach:
*Can interactive shell commands execute on the dispatcher, or do they only run on the DUT?*
In my use case, I need to execute Redfish API calls from the dispatcher (the dispatcher has network access to the BMC at 192.168.xx.xx, while the DUT is the BMC itself connected via serial console). If interactive shell runs on the DUT, I'm not sure how it would help me avoid modifying the device dictionary for dispatcher-side commands.
Could you provide a brief example or point me to documentation showing how to use interactive shell to run commands on the dispatcher with dynamic parameters from the job file?
Also, I tried joining the Discord server using the link you provided ( https://discord.com/channels/1412434677477937203/1412434677477937211), but I see "NO TEXT CHANNELS" - it appears I don't have access or the link might be incorrect. Could you verify the invite link or let me know if there's a verification process I need to complete?
Thank you for your patience and help!
Best regards, Mor
בתאריך יום ב׳, 3 בנוב׳ 2025 ב-10:53 מאת Milosz Wasilewski < milosz.wasilewski@foundries.io>:
Mor,
On Sun, Nov 2, 2025 at 3:32 PM מור נגלי naglimor267@gmail.com wrote:
Hello LAVA community,
I'm working with LAVA for automated testing of embedded systems with BMC
(Baseboard Management Controller) and I've encountered a limitation that I'd like to ask about.
My Use Case
I'm testing devices that support Redfish API for power management. I
need to execute various Redfish commands (forceoff, poweron, forcerestart, etc.) from the dispatcher during test jobs. Currently, I define these as user_commands in my device dictionary:
jinja2
{% set user_commands = { 'redfish_forceoff': { 'do': '/opt/lava-lab/shared/lab-scripts/dispatcher_command.sh
192.168.17.111 forceoff'
}, 'redfish_poweron': { 'do': '/opt/lava-lab/shared/lab-scripts/dispatcher_command.sh192.168.17.111 poweron'
}, # ... more commands} %}
Then in my job file:
yaml
- command: name: redfish_forceoff
The Problem
Every time I need to add a new Redfish action, I must modify the device
dictionary (Jinja file) to add a new user_command entry. I'd like users to be able to specify the action dynamically from the job file without requiring device configuration changes.
What I want to achieve:
yaml
# In job file - specify action dynamically context: redfish_action: forceoff
actions:
- command: name: redfish_command # Generic command that uses context variable
What I've Investigated
Deploy actions support variable substitution (e.g., {IMAGE}), but this
is hardcoded for deploy actions only
Job context variables can override device dictionary values, but only at
device configuration rendering time (job parsing), not at action execution time
user_commands are static strings with no runtime parameter substitution
mechanism
Test definitions support parameters, but they run on the DUT, not the
dispatcher
I understand from the documentation that dispatcher commands are
intentionally restricted for security reasons, which makes sense.
My Current Workaround
I'm using Jinja2 loops to auto-generate commands from a list:
jinja2
{% set redfish_actions = ['auth_test', 'forceoff', 'poweron',
'forcerestart'] %}
{% set user_commands = {} %} {% for action in redfish_actions %} {% set _ = user_commands.update({'rf_' + action: {'do': rf_script +
' ' + action}}) %}
{% endfor %}
This reduces the pain (just add one word to a list), but still requires
device configuration edits.
My Questions
Is there any mechanism I've missed that allows passing runtime
parameters from job files to user_commands?
No, there isn't.
Is this a known limitation that others have encountered?
Yes, this is a limitation. Other limitation (comparing to other "commands") is that user_commands don't accept lists - only a single string. For example power_on and power_off commands accept lists.
Would it be feasible to add support for parameter substitution in
user_commands (similar to how deploy actions work with {IMAGE}), while maintaining security constraints?
Given the commands are executed on the dispatcher it might be a big lift. It's really hard to say without any implementation proposal.
Are there alternative approaches within LAVA's architecture that I
should consider?
You can try interactive shell: https://validation.linaro.org/static/docs/v2/interactive.html https://validation.linaro.org/static/docs/v2/interactive.html The commands you execute come as part of a test job. So you still need to generate them somehow but there is no need to change the device dictionary for that.
Any guidance or suggestions would be greatly appreciated. If this is a
feature that doesn't exist but would be useful, I'd be happy to discuss potential implementation approaches or contribute to a feature request.
Send a PR and we can discuss there. Alternatively you can join discord and ask there: https://discord.com/channels/1412434677477937203/1412434677477937211 https://discord.com/channels/1412434677477937203/1412434677477937211
Best Regards, Milosz