update-member throws 404

[David Rabel]

Hi, I'm using PackStack with OpenStack Rocky release.

When creating an image in project1 and adding project2 as a member to it, project2 has pending status for the image. That's correct so far.

When switching to a user from project2 (_member_ role in that project) and trying to do a glance member-update, it fails with a 404. The image cannot be found. It works neither with OSC nor with glanceclient, so it might be a bug in Glance itself.

# glance-api --version
17.0.0

# glance --version
2.13.1

# openstack --version
openstack 3.16.2

[Abhishek Kekane (abhishek-kekane)]

Marked as incomplete as title says update member fails but description talks about image update, need more information on this.

[David Rabel (rabel-b1)]

I meant glance member-update... Fixed it in the original description.

[Brian Rosmaita (brian-rosmaita)]

Some general information: When v2 image sharing was implemented in Grizzly, the thinking was that making a call to keystone to verify that the ID of the member was a known project ID was too expensive, so it wasn't implemented. The implication of this decision is that when you create an image member, glance will accept anything of the correct type, which is a JSON 'string' type:

curl -s -X GET -H "x-auth-token: $TK" "$OS_IMAGE_URL/v2/schemas/member" | python -m json.tool
{
    "name": "member",
    "properties": {
        "created_at": {
            "description": "Date and time of image member creation",
            "type": "string"
        },
        "image_id": {
            "description": "An identifier for the image",
            "pattern": "^([0-9a-fA-F]){8}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){12}$",
            "type": "string"
        },
        "member_id": {
            "description": "An identifier for the image member (tenantId)",
            "type": "string"
        },
        "schema": {
            "readOnly": true,
            "type": "string"
        },
        "status": {
            "description": "The status of this image member",
            "enum": [
                "pending",
                "accepted",
                "rejected"
            ],
            "type": "string"
        },
        "updated_at": {
            "description": "Date and time of last modification of image member",
            "type": "string"
        }
    }
}

Note that while the image_id must be a UUID, the member_id is simply a 'string' type.

Now, notice what happens when you get info about a user's project:

demo! openstack project list
+----------------------------------+--------------------+
| ID | Name |
+----------------------------------+--------------------+
| 37505bc7dd024ceaadfa21f16d3aee33 | invisible_to_admin |
| 4d0255bb8ac04dcf9fc0f53126c88cde | demo |
+----------------------------------+--------------------+

The response above is for my devstack 'demo' user. Note that the project IDs are NOT in hyphenated UUID format.

Now I am going to switch to being my alt_demo user and try to share an image with the 'demo' user who is in project 4d0255bb8ac04dcf9fc0f53126c88cde.

First, the osc help (abbreviated)
alt_demo! openstack help image add project
usage: openstack image add project <image> <project>

Associate project with image

positional arguments:
  <image> Image to share (name or ID)
  <project> Project to associate with image (name or ID)

So here are a series of calls trying to share image 1c952398-92a2-4c10-b543-74e4b31f41e1 owned by alt_demo's project with the demo project.

First, before the image is shared:
demo! glance image-show 1c952398-92a2-4c10-b543-74e4b31f41e1
404 Not Found: No image found with ID 1c952398-92a2-4c10-b543-74e4b31f41e1 (HTTP 404)

OK, what we expect. Let's share it.
First, see if there are any members:
alt_demo! glance member-list --image-id 1c952398-92a2-4c10-b543-74e4b31f41e1
+----------+-----------+--------+
| Image ID | Member ID | Status |
+----------+-----------+--------+
+------...

[Brian Rosmaita (brian-rosmaita)]

@David: please read through the above and let us know if it explains what you're seeing.

[David Rabel (rabel-b1)]

Hi Brian,

you are right. Thank you very much for this detailed explaination!

But I still see this as a problem.

I already tried to "fix it" by only allowing the ID from the OSC point of view, but this does not seem to be satisfying as well.

So I wonder if and how we could add verification of the project parameter.

Please also have a look at the (short) discussion in my change request for OSC:

https://review.openstack.org/#/c/638495/