v2 Image Member Create Does Not Accept member_id

[Ian Cordasco]

Glance v2 Image Member Creation's schema file says that it requires a member_id attribute as part of the JSON POST body. The controller, however, only looks for member and the API is documented that way here: http://developer.openstack.org/api-ref-image-v2.html#createImageMember-v2

As a matter of backwards compatibility, Glance should accept both member and member_id in the POST body but prefer member_id.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/259160

[OpenStack Infra (hudson-openstack)]

Change abandoned by Glance Bot (<email address hidden>) on branch: master
Review: https://review.openstack.org/259160

[Castulo J. Martinez (castulo-martinez)]

I just came across this problem when trying to create an image member, I was trying to use the member_id as the documentation suggests only to find out the only way to make it work is through using member instead of member_id (opposite of what documentation says). I was going to open a documentation bug to ask for the documentation to be updated, but then I found this bug. What is the status of this bug? Is this still targeted to be fixed? If not then the documentation needs to be fixed.

[Brian Rosmaita (brian-rosmaita)]

Not taking a position on correctness here, but I don't think there is a schema for the member-create request. There's one for the response, but not the request.

[Brian Rosmaita (brian-rosmaita)]

Note: At some point the API Reference was updated as if this bug had been fixed in the way Ian proposes above. The patch I currently have up for the WADL -> RST conversion of the API Ref changes the text to describe the current (unfixed) behavior.

This is just a note that whoever picks up this bug should put both "DocImpact" and "APIImpact" flags on the commit message

[Brian Rosmaita (brian-rosmaita)]

This has been discussed in the past few glance meetings, and we've decided that the fix for this is to adjust the schema to reflect the actual coded behavior. That way there will be no question about backward compatibility. The proposed schema was discussed at the API WG meeting last week, and they are OK with this way of fixing the problem.

See https://bugs.launchpad.net/glance/+bug/1585917/comments/3 for the proposed schema and https://bugs.launchpad.net/glance/+bug/1585917/comments/5 for a link to the API WG conversation.