python-openstackclient incorrectly calls cinder metadata 'properties'

[Duncan Thomas]

The term 'metadata' is used on horizon, in the rest API, in the cinder docs, in python-cinderclient and in various third party libs, as well as in the code and in bugs.

Calling it 'properties' is a cause of confusion, and was never communicated to the Cinder team; indeed I've recently had to remove the term 'properties' from a generic volume groups proposal because of this, where properties was actually the right term to be using.

[Dean Troyer (dtroyer)]

OSC aims to be internally consistent and this is a good example of one of the places we will differ from the project in terminology. There is a tradeoff in being different from the project or the projects being different from each other. We chose to differ from the project in order to maintain a consistent user interface.

[Sheel Rana (ranasheel2000)]

Dear Dean,

I respect your points. But I am more inclined towards this bug.

Let me explain why..

This may be ok if we are using property for metadata in OSC.
But corresponding component must be informed about changes
for their counterparts for better user experience.(I am explaining further what i mean by better user experience)

Further, this may not be related as components are different and their implementations
are independent.
So, keeping different names may be ok, which is fair enough.

But actual thing is that there are certain documents/components which use metadata instead of property.
In case user see metadata in docs or related component but property in OSC, then this may spoil the target for achieving good user experience.

Also, we are trying to generate single CLI for user in OSC in same way as we have single horizon for GUI.
But here also we are loosing similarity in terms as horizon displays metadata.

So, I would suggest to keep parity for different terms upto the extend it is possible.

This may be discussed and decided whether property should be changed to metadata or vice-versa.
But something needs to be changed.

Simple suggestion from my side for future implementations:
We can make it must to have +1 from one member of specific component before getting this merged to OSC for proof of acceptance.
We can ask for creating liaison(1 or 2 members from specific component) as per acceptance from their cores.

Thank you for your understanding!!