[feature] Additional commissioning script parameters

Bug #1881916 reported by Angela Piotrowski on 2020-06-03
This bug affects 4 people
Affects Status Importance Assigned to Milestone

Bug Description

Commissioning script parameters as described in the documentation are misleading. It seems the only parameter available today is storage. This request is to allow any parameter to be passed, this would not only include other metadata fields like interfaces but also user-defined parameters that could be provided either through the UI or API upon commissioning of the system.

Lee Trager (ltrager) wrote :

As of MAAS 2.7 there are 3 parameters available

storage - Accepts storage devices
interface - Accept interfaces
url - Accepts URLs

No other parameter is currently supported. I had originally planned on implementing other types(string, text, bool, integer, etc) however it proved difficult to add to the UI.

Are you requesting the docs to be improved explaining the currently available parameters or for new parameters types to be added?

tags: added: doc
Victor Tapia (vtapia) on 2020-06-04
tags: added: sts
Lee Trager (ltrager) on 2020-06-04
Changed in maas:
status: New → Incomplete
Matthew Swart (mswart343) wrote :

Mentioned this in the original case as well:
"The reason for this request is because the parameters field the way it is defined makes it sound like it should support the ability to pass in any var. It's not until you dig into the actual underlying values that you see it was really only added to support the storage piece. This discrepancy leads me to believe it was created with the idea of expanding its use in the future. I would consider this as either a feature request or possibly an update to documentation."

To fully answer the question, in the short-term this is a request to update the documentation such that the field causes less confusion. In the long-term however, I would consider this to be our main request for commissioning scripts. Without additional parameter types creating scripts that work dynamically with different skus becomes rather tedious. To further expound on this, provided is the example given in the case.

"... we have two commissioning scripts created, for Dell and Supermicro, to update Bios/Bmc. These scripts support different skus, we do this by defining a list of dicts (in python) containing the values necessary for an update. That python is then imported into the main python script and run through templating to output a switch case statement using ifs based off the mainboard product, which is then injected into the com script and uploaded. There are other other pieces that are injected as well, such as for supermicro the are variations of the bios config that could be applied. This would be easy to solve if we could have the python decide which config is correct and then pass it in as a parameter that gets picked up by the script. However because that isn't available we have to make another switch case for each of the skus and at the top keep a constant tally on which config belongs to which host."

Hopefully this helps understand the reasoning behind the request. Also, using this as an example, it would be a decent idea for support to include a link to the case, if that is where the request originates.

TL;DR, yes improving the explanation in the docs would be a solution for this case.

Matthew Swart (mswart343) wrote :

In response to "... however it proved difficult to add to the UI". Thinking of two possible solutions.

1. Commissioning scripts that require parameters are not automatically run and do not show up in the list of available scripts in the UI. Don't see this as a viable option as it requires a large number of checks and filtering, and seems a bit of a hacky solution.

2. For reference, when I mention a drop-down I mean something similar to the page with the options for the commissioning script that drops down. You could either have a drop-down for each commissioning script that requires parameters or a single drop-down with some sort of paging. Should be dynamically sized by the number of parameters (possibly put a max on the number of parameters). The drop-down would have the script name at the top, a dynamic table of all parameters, and a 'continue' button that moves forward with the commissioning after checking each parameter (if required) is filled. Also, because the parameters are statically typed it should be simple to add in dynamic type checking as well as sanitize input. This is probably the more preferred solution, however it would be a decent amount of work adding in a dynamic drop-down with a variable number of scripts and parameters.

Just some thoughts, let me know what you think.

Changed in maas:
status: Incomplete → New
tags: added: ui
Lee Trager (ltrager) wrote :

We've updated the docs to try and better explain how parameters work.

I had originally wanted to add various parameters that users could input such as selection fields, string, integers, runtime, etc however these provided difficult to implement UI for. I'll keep this bug open as a wish list as I do hope to add more parameter input types in the future.

In the meantime I've opened LP:1883333 which will allow you to create scripts which when selected will only run on systems with matching hardware. For example the script below will only run when select on hardware with a system SKU MY_SKU.

#!/usr/bin/env python3
# --- Start MAAS 1.0 script metadata ---
# name: sku-test
# tags: sku
# script_type: commissioning
# for_hardware: system_sku:MY_SKU
# --- End MAAS 1.0 script metadata ---

print("SKU matched!")

Changed in maas:
importance: Undecided → Wishlist
no longer affects: maas-ui
Changed in maas:
status: New → Triaged
Changed in maas-ui:
importance: Undecided → Unknown
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.