| 2017-01-11 13:43:27 |
Sam Betts |
description |
Currently the /drivers/properties API outputs property information in a json like
{
property_name1: <description>
property_name2: <description>
}
Often the description includes information such as whether the property is required or optional or if it depends on another properties value. This information in its current form is useful for users using the CLI to call this API, however it isn't so useful for cases when a machine might call this API, for example when trying to build a GUI form for enrolling a node of a particular type. The only option right now is to parse the description string with a REGEX, but with no defined standard this might not always work.
This RFE is proposing to enhance the /drivers/<driver_name>/properties API to with a ?detail=True query which would respond with a json in a more machine readable format for example:
{
property_name1: { description: <description>,
required: <true|false>,
depends-on: [<another property name>]
},
property_name2: { description: <description>,
required: <true|false>
}
}
additionally, to accommodate for standardising in the API, a more standardised way to define driver properties in the driver modules would be provided, using a similar (or the same) interface as the oslo.cfg opts definitions that allows a driver developer to define a property as an object with fields like required=True and also to type the options like str option or bool option in oslo.cfg. This will allow the Ironic code for parsing, returning and validating properties for drivers to be simpler, more consistent and common across multiple drivers, avoiding the duplication of property parsing we see today in many drivers. |
Currently the /drivers/properties API outputs property information in a json like
{
property_name1: <description>
property_name2: <description>
}
Often the description includes information such as whether the property is required or optional or if it depends on another properties value. This information in its current form is useful for users using the CLI to call this API, however it isn't so useful for cases when a machine might call this API, for example when trying to build a GUI form for enrolling a node of a particular type. The only option right now is to parse the description string with a REGEX, but with no defined standard this might not always work.
This RFE is proposing to enhance the /drivers/<driver_name>/properties API to respond with a json in a more machine readable format for example:
{
property_name1: { description: <description>,
required: <true|false>,
depends-on: [<another property name>]
},
property_name2: { description: <description>,
required: <true|false>
}
}
There are two possibilities for preventing API breakage here, either have the new view protected by microversions or only displaying this view if you provide a ?detail=True query. Which of these is TBD.
Additionally, to accommodate for standardising in the API, a more standardised way to define driver properties in the driver modules would be provided, using a similar (or the same) interface as the oslo.cfg opts definitions that allows a driver developer to define a property as an object with fields like required=True and also to type the options like str option or bool option in oslo.cfg. This will allow the Ironic code for parsing, returning and validating properties for drivers to be simpler, more consistent and common across multiple drivers, avoiding the duplication of property parsing we see today in many drivers. |
|
