I've had some doubts but now it gets clear to me that problem is unsolvable in a decent way without changes to Glance. Problem with API differences was described well in the bug report.
Looking in the Cinder code we can see that a few image attributes are hardcoded and are always passed from image to the volume (checksum, container_format, disk_format, min_disk, min_ram, size). This is fine, these are passed correctly using v2 API.
Problem arises when we want to introduce custom properties. Using Glance v2 API these are indistinguishable from core properties (aka attributes). The only way to determine which are custom would be to download the Glance image schema and see if the property is on the attribute list. This may be even achievable using is_core_property method from glanceclient.v2.schemas.Schema. I don't like the idea of Cinder downloading Glance's schema but okay...
What's blocking are properties that are "not base" - for example kernel_id (there's "is_base" : false in its schema). Cinder should pass these to the volume but the only way to distinguish these would be to analyze raw schema for is_base attribute set to false. This is totally unacceptable.
I would suggest that Glance should somehow differentiate attributes and properties so Cinder would know what to pass to the volume metadata.
I've had some doubts but now it gets clear to me that problem is unsolvable in a decent way without changes to Glance. Problem with API differences was described well in the bug report.
Looking in the Cinder code we can see that a few image attributes are hardcoded and are always passed from image to the volume (checksum, container_format, disk_format, min_disk, min_ram, size). This is fine, these are passed correctly using v2 API.
Problem arises when we want to introduce custom properties. Using Glance v2 API these are indistinguishable from core properties (aka attributes). The only way to determine which are custom would be to download the Glance image schema and see if the property is on the attribute list. This may be even achievable using is_core_property method from glanceclient. v2.schemas. Schema. I don't like the idea of Cinder downloading Glance's schema but okay...
What's blocking are properties that are "not base" - for example kernel_id (there's "is_base" : false in its schema). Cinder should pass these to the volume but the only way to distinguish these would be to analyze raw schema for is_base attribute set to false. This is totally unacceptable.
I would suggest that Glance should somehow differentiate attributes and properties so Cinder would know what to pass to the volume metadata.