Metadata widget should deal with non-unique properties

[Julie Gravel]

Currently if there's a property that appears in more than one namespace (hence non-unique) and the user selects that property from one of the namespace, the Metadata widget will remove it from only one of the namespaces. When the user reloads the widget, it will just remove that property from whichever namespace it processes first while other namespaces will still display the property.

Having the same property in different namespaces is a possible scenario for Cinder's volume type extra specs where there is no guarantee that different drivers will use unique extra spec keys.

The widget should remove the property from ALL namespaces after the user selects it. This is so that the same property will not show up again in other namespaces after a reload.

[Gary W. Smith (gary-w-smith)]

Without this change, it limits where the widget can be used

[Szymon Wróblewski (bluex)]

It was designed to work only with unique properties, as there is actually no way to deal with ambiguity.

Name is the only thing distinguishing different properties and in case of two different properties existing with same name in different namespaces, there is no way to explicitly choose on of them. If non-unique properties will be allowed, then behavior of all property features (like validation, label, description, select predefined values, etc.) will be unpredictable, because settings from first found property in namespaces will be used.

Proper solution would be to use different prefixes (ex. namespace name) for all identical properties.

[Travis Tripp (travis-tripp)]

To expand on Szymon's points, there are a few workflows to talk through. Perhaps volume type / QOS specs could be used interchangeably in my example below:

1) Initial add of the property. User opens volume type and wants to add a property.

In this case, it would be easy to remove all instances of the property from the list of available properties. The right hand side where you edit the property value and the description would know which particular property it was selected. The correct input validation constraints from that property could be used, because the actual property could be tracked in the UI state as long as the edit form is open.

2) Modifying existing properties. User opens volume type and want to view / modify properties.

A volume type just has properties. A UI could easily detect that property “my_property” exists in two namespaces and remove all instances of that property from the selection of available properties, but it would not be able to know which validation constraints to apply, which display name to apply, or which description to apply. Does “my_property” really belong to driver A or to driver B?

To disambiguate the properties, you’d need some way to track who the property applies to. Perhaps you could have a second property that tracks the property source. E.g.: ‘property_source[‘my_property’]’ : ‘driver_a’.

This, however, is just a convention and you’d have to ensure it is ALWAYS used, whether from command line, API, or UI. Otherwise you again hit the ambiguity problem, which I think would be a problem for any UI.

The widget right now gets its data from the horizon view associated with the type of resource (e.g. Volumes). So, maybe there would be opportunity to sort some of this out there, but you’d first have to think about how to handle scenario 2 above.

[Travis Tripp (travis-tripp)]

Has this been completed?

[Szymon Wróblewski (bluex)]

Yeah https://review.openstack.org/#/c/157367/
But'll probably need to rebase it again.

[Szymon Wróblewski (bluex)]

@Travis: Take a note that this patch also changes how metadata-display works in launch instance .
Previously only last matching namespace was used do display ambiguous property. Now all matching namespaces are displayed.

[OpenStack Infra (hudson-openstack)]

Change abandoned by David Lyle (<email address hidden>) on branch: master
Review: https://review.openstack.org/157367
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.