It would be very helpful to put the address of the applicable Rack Controller into the environment prior to the TEST and/or COMMISSION scripts execute.
More generally, it would be helpful to have a section allowing arbitrary environment variables to be defined. In the GUI, have it be “parallel” to the TEST and COMMISSION scripts section (applying to both). From the CLI, something like node-script environment+=.
The SquashFS, which contains the root filesystem of the ephemeral environment, comes from the rack controller. This is defined on the kernel command line. The rack-controller-connectivity test gets the rack URL as follows:
# When booting into the ephemeral environment root is the retrieved from
# the rack controller.
for i in $(cat /proc/cmdline); do
arg=$(echo $i | cut -d '=' -f1)
if [ "$arg" == "root" ]; then
value=$(echo $i | cut -d '=' -f2-)
# MAAS normally specifies the file has "filetype:url"
filetype=$(echo $value | cut -d ':' -f1)
if [ "$filetype" == "squash" ]; then
url=$(echo $value | cut -d ':' -f2-)
else
url=$filetype
fi
break
fi
done
MAAS does not have a way to include arbitrary environmental variables however there are two ways to work around this.
You can include a script which defines variables and sources it. Testing scripts tagged with commissioning run by default. Commissioning and testing scripts are stored in separate directories adding source ../testing/my-vars should work for a test script named my-vars to be included in both commissioning and testing scripts.
MAAS 2.9 added support for string, password, and choice script parameters. MAAS does not currently have UI support, they are only available on the command line. These options are used by 30-maas-01-bmc-config to pass BMC parameters. I did a Show & Tell on this a few months back which shows how to create your own custom script.
just after your code did the trick.
if you are so inclined, peek a case 00307172 where it appears support and I have differing views of what “commissioning” “runs by default” and “for_hardware” are intended to mean when combined.
Hopefully, my understanding of the intention is right, and I’ve got a bug.
It should be noted that when executing “test” only the testing scripts that are active seem to be downloaded, and none of the commissioning scripts.
So it might be helpful to have a third kind … a “utility” category, which is always downloaded (so could be counted on by either COMMISSIONing or TESTing scripts). These could be variables, functions, or whatever. Or if not an entire third category, a single special script which could contain this sort of thing (although I’d prefer the former approach, as that generalizes for uses other than just bash environmental (ruby, perl, python … whatever or however many variations folks turn out to require).
All commissioning scripts are selected by default unless enlistment is running. In that case a commissioning script must be tagged with enlisting. A testing script can be automatically selected if it is tagged with commissioning. If you use a commissioning script use source ../commissioning/my-vars. I only mentioned a testing script because commissioning scripts are not sent if only testing is running.
Thanks for the suggestion we will take it into consideration as we make improvements to MAAS.
