glance image-list does not return shared images using v1 api

[Nathanael Burton]

Listing images using "glance image-list" does not seem to return shared images. This appears to be a regression. I discovered this when looking into bug #1114821 and also ran across bug #1098700

Testing with devstack and master (the same testing works fine on stable/folsom):
mathrock@devstack:~/devstack$ source openrc admin admin
mathrock@devstack:~/devstack$ glance image-create --name "cirros-test-shared-image" --disk-format qcow2 --container-format bare --is-public False --copy-from https://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-x86_64-disk.img
mathrock@devstack:~/devstack$ glance image-list | grep shared
| de18981e-1b72-4467-b2a4-5bc69cb09c56 | cirros-test-shared-image | qcow2 | bare | 9761280 | active |

mathrock@devstack:~/devstack$ source openrc demo demo
mathrock@devstack:~/devstack$ glance image-list | grep shared

mathrock@devstack:~/devstack$ source openrc admin admin
mathrock@devstack:~/devstack$ glance member-create de18981e-1b72-4467-b2a4-5bc69cb09c56 254593691e45404cb8b683b2d713aff1
mathrock@devstack:~/devstack$ glance member-list --image-id de18981e-1b72-4467-b2a4-5bc69cb09c56
+--------------------------------------+----------------------------------+-----------+
| Image ID | Member ID | Can Share |
+--------------------------------------+----------------------------------+-----------+
| de18981e-1b72-4467-b2a4-5bc69cb09c56 | 254593691e45404cb8b683b2d713aff1 | |
+--------------------------------------+----------------------------------+-----------+

mathrock@devstack:~/devstack$ source openrc demo demo
mathrock@devstack:~/devstack$ glance image-list | grep shared
mathrock@devstack:~/devstack$ glance image-list
+--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
| ID | Name | Disk Format | Container Format | Size | Status |
+--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
| 1fd5bd38-31cc-48c4-97a1-c603cfc5fa88 | cirros-0.3.1-x86_64-uec | ami | ami | 25165824 | active |
| 344ef6b7-9108-494b-ab05-d20bca396668 | cirros-0.3.1-x86_64-uec-kernel | aki | aki | 4955792 | active |
| 415726bc-8276-42c2-b7a1-bbcf5e28f31e | cirros-0.3.1-x86_64-uec-ramdisk | ari | ari | 3714968 | active |
+--------------------------------------+---------------------------------+-------------+------------------+----------+--------+

[Iccha Sethi (iccha-sethi)]

This is happening because of migration 16, where the default value of member status is requested and unless an image has not been accepted, it is not displayed in the list.

[Nathanael Burton (mathrock)]

I did notice that in the 'image_members' table that all the rows had a status='pending'. So is the problem that the code is not updating the newly added status column when 'glance member-create' is run?

[Nathanael Burton (mathrock)]

OK, I just read https://wiki.openstack.org/wiki/Glance-api-v2-image-sharing and now better understand the status column. Does the mechanism for a user to accept/reject a shared image exist yet? Also when doing migration 16 if there were existing shared images that users were already using, wouldn't we want the migration to default to 'accepted' rather than 'pending'?

[Iccha Sethi (iccha-sethi)]

Yup there are pros and cons to it. The pro being it preserves the v1 behavior, the con being as soon as the user uses v2, there is no option of accepting the images, they get carried over immediately as accepted. What are your thoughts?

[Nathanael Burton (mathrock)]

I personally would prefer to not break the v1 behavior for existing shared images and have them be accepted upon migration. Based on the v2 image sharing spec there appears to be a way to change an 'accepted' share to 'rejected' if you no longer want to see it. So v2 users could always just reject images they don't want to see that were turned into 'accepted' images by the migration.

However this is all separate from my original bug, which may not be a bug but rather how the new image sharing is supposed to work. If so, the main two questions are:

1. For migration 16, is adding the status column as is currently implemented by defaulting to 'pending' what we want? My opinion is it should default to 'accepted'.

2. Is the new behavior documented and does python-glanceclient currently support making the API call to accept/reject a share request?

[Iccha Sethi (iccha-sethi)]

Yes I agree about version 1 not breaking. And I will change the default to accepted/

There is no documentation yet, and glanceclient doesnt support image members for glance v2 api. The code for v2 image sharing was just merged in last week. Both will be in progress soon.

[Nathanael Burton (mathrock)]

Sounds good

[Mark Washenberger (markwash)]

So the fix for this is to use member_status='all' in the v1 db calls, correct?

[Nathanael Burton (mathrock)]

@Mark you are correct

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/23349
Committed: http://github.com/openstack/glance/commit/effda5d66f7d084133fbe0b49d7ef6d0ca178e4a
Submitter: Jenkins
Branch: master

commit effda5d66f7d084133fbe0b49d7ef6d0ca178e4a
Author: mathrock <email address hidden>
Date: Sat Mar 2 14:20:08 2013 -0500

    v1 api image-list does not return shared images

    The addition of the status column on image_members for the v2 api broke
    backwards compatibility with the v1 api image members feature. This fix
    forces that member_status='all' is passed to all v1 api calls to ensure
    the v1 image members feature still works.

    Note: Any images shared prior to migration 016 will be marked as 'pending'
    yet will still be accessible via the v1 api since v1 has no notion of
    image 'member_status'. Additionally, any new images shared via the v1 api
    will follow the same behavior, being marked as 'pending'. In order for
    shared images to be used with v2 they will need to have a 'member_status'
    of 'accepted'.

    Change-Id: I0ab9397e3663c6e2af8a18838f56803e64d84595
    Fixes: bug #1132294
    DocImpact