Consider renaming `Volume.attributes`

[saad-ali]

Low priority, but I've had several people mention to me that attributes is a confusing name:

message Volume {
  map<string, string> attributes = 3;
...

This field should be opaque to CO. But attributes suggests that it contains "volume attributes". Which is not the intention.

Maybe call it server_context or something else?

[saad-ali]

Other options: cookie, plugin_attributes, driver_context?
oem vs plugin: CO doesn't care between these two.
Another option "Just call it volume_oem and publish_oem like redfish swordfish"
OEM or vendor?
volume_vendor and publish_vendor?
Vendor specific attributes over and above the standard set.
volume_vendor_attributes and publish_vendor_attributes?

We should also be consistent with the naming of ControllerPublishVolumeResponse.publish_info

volume_context, publish_context? context should be passed in everywhere
volume_cookie, publish_cookie? mutable, where as these are not.

Option: leave it as is, and make documentation clearer?

Conclusion: none. Discuss here.

[saad-ali]

There are a number of these "opaque key/value bags" in the API, another one is currently called manifests in GetPluginInfoResponse. We should make sure the naming we decide on is consistent for all of these.

[saad-ali]

I'll create a PR saying ...context..., and we'll go from there.

[saad-ali]

There are a number of these "opaque key/value bags" in the API, another one is currently called manifests in GetPluginInfoResponse. We should make sure the naming we decide on is consistent for all of these.

Will not rename manifest unlike volume_attributes and publish_info it is not passed in on subsequent operations, so context doesn't make sense for that field. I don't have a better name for it, so I will leave manifest as is.