MAAS passes a commissioning script parameter type instead of its name as a command-line argument name
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Fix Committed
|
High
|
Andrew Lamzed-Short |
Bug Description
MAAS currently passes a commissioning script parameter type instead of its name as a command-line argument name when invoking commissioning scripts with argument types other than "storage" or "interface".
https:/
else:
)
ret += argument_
For example, using the "url" parameter type (https:/
parameters:
interface:
type: interface
foo:
type: url
default: https:/
bar:
type: url
default: https:/
will result in a commissioning script to be called as:
<script-name> --url https:/
Instead of:
<script-name> --foo https:/
Related branches
- MAAS Lander: Approve
- Jack Lloyd-Walters: Approve
-
Diff: 97 lines (+28/-14)2 files modifiedsrc/metadataserver/user_data/templates/snippets/maas_run_remote_scripts.py (+9/-14)
src/metadataserver/user_data/templates/snippets/tests/test_maas_run_remote_scripts.py (+19/-0)
description: | updated |
description: | updated |
Changed in maas: | |
assignee: | nobody → Andrew Lamzed-Short (andyls) |
Changed in maas: | |
status: | Triaged → Fix Committed |
rare that i *don't* need a reproducer, but this seems like one of those times. given i'm triaging this one on logical analysis alone, i'd better share my thinking, so someone can slap me if i'm wrong:
- the code snippet (indeed from the MAAS code) shows that the argument format defaults to `param_type` if no `argument_format` is present.
- this does indeed mean that the code's constructing argument names based on type, rather than parameter names, as intended.
- the given example bears this out.
the expected behavior, based on MAAS documentation (hey, i *wrote* that) and typical command-line conventions, is to use named parameters so that scripts can actually *differentiate* between the passed arguments. that clearly ain't happenin' here, y'all. again quoting myself, the MAAS commissioning and hardware testing scripts documentation says that parameters are meant to be passed to scripts with specific names that the scripts will recognize. again, ain't happening.
that makes this a bug, for sure, imnsho.
this is a bit problematic, since this leads to ambiguity in script execution, since the script would tell the two apart. this can cascade to unexpected arguments, causing runtime errors, incorrect behavior, or just general weirdness.
triaging this and giving it some heat.