Provide the ability to adjust a script's timeout value

[Jose Delarosa]

From bug 1888721, I understand that scripts can't be directly edited, but can arguments be passed or read from a user-defined environment variable?

[Lee Trager (ltrager)]

When I originally designed the hardware testing frame work I had planned to accept many types of user parameters. I was able to implement runtime input before we decided to not accept string, int, bool, etc types. The implementation is pretty basic but it may do what you want. You can add a runtime parameter to any script. By default the runtime will be the timeout value. If a user specifies a runtime it will override the timeout with the runtime. Runtime is only passed to the script as the environment variable $RUNTIME. Using the attached script as an example you can change the timeout from 5 minutes to 42 seconds as follows

maas $PROFILE machine test $SYSTEM_ID testing_scripts=user-timeout runtime=42

Runtime input is only accept over the API and must be given in seconds.

This requires the script to be modified to accept the runtime parameter so you'll still need to create a separate copy of any builtin script you want to use this with. Is this what you're looking for? Why do you need to change the timeout of any of the builtin scripts?

[khb (khbkhb)]

Runtime was an example; specifically, brand new or repaired HW by our policy should have runtime of 24-72 hours (depending on circumstances, and which part of the company). There is a perfectly sensible stress-ng-cpu-long but it only runs 12 hours. So it's a fine example of why we'd like there to be supported ways to adjust the parameters. In addition, we observed several timeout failures ... we'd queued up multiple tests, and -long having a timeout that was identical to the runtime seemed like a likely culprit (the hw passes multi-day vendor stress testing, and the only error reported by MAAS was timeout). So the most obvious proposed change (keep the runtime, change the timeout) even required forking the test.

So, just runtime isn't what we seek. But clearly you've already put the framework in place, so it would seem like a fairly low effort RFE to
1) Allow any VAR=$VALUE to be used by a script as $VAR
2) Adjust the built in scripts to accept runtime, timeout, and perhaps threads (any other major control variables that make sense ;>)

[Lee Trager (ltrager)]

The original plan was to ship tests with configurable variables such as runtime, threads, and other configuration options. The smartctl and stress-ng tests were supposed to be one test with different configuration options instead of separate tests. I got the framework working for this but the UI design ended up becoming too complex for our design team to complete. I think we should revisit that decision since design was able to implement input of URLs for network testing last cycle.

I'm tagging this ui since the original blocker for this feature was the design team. We will still need some backend work to implement new parameter types(int, string, boolean, and selection).

[Jerzy Husakowski (jhusakowski)]

Feature request moved to the internal project feedback backlog for future prioritisation.

[Thorsten Merten (thorsten-merten)]

setting to invalid for maas-ui as per Jerzy's comment above