To Reproduce Steps to reproduce the behavior:

1. Deploy RHOSO18

• There are two projects, tenantA and tenantB.
  1. Create an image in tenantA as private image
  2. Change private to shared.
  3. Run 'openstack image add project < image UUID > < tenantB UUID > in tenantA
  4. In tenantB, admin role user for tenantB accept the member list as
  openstack image set --project < tenantB UUID > < Image UUID >
  5. Check openstack image member list < Image UUID > to confirm the
  status is accepted.
  The curious thing is that the owner of the image was changed to
  tenantB after the step 4.
  By this behavior, the user in tenantA cannot see the image even though
  the image producer is a user in tenantA.

Expected behavior

• At step4, owner of image won't change, remains as tenantA

Bug impact

• By this behavior, the user in tenantA cannot see the image even though
  the image producer is a user in tenantA.

Known workaround
1. Using separate commands:

1. In tenantB, accept the membership (without --project)
   openstack image set --accept <image_id>
2. If you need to specify a different project, use the member update API directly
   openstack image member set <image_id> <tenantB_id> accepted

2. Or manually add tenantA back as a member and accept it.

Additional context
Abhishek Kekane provided the detailed analysis.

Thank you for bringing this up. After investigating the codebase, I can confirm that this is not expected behavior - it's a bug in the OpenStack client (openstackclient).

• Root Cause
  The issue occurs in the openstack image set command when both --project and --accept flags are used together. The command incorrectly interprets the --project parameter as both:

The project whose membership should be accepted (correct)
The new owner of the image (incorrect - this is the bug)
According to the Glance API specification [1], accepting a member should only change the member status from pending to accepted. The image owner should remain unchanged. The Glance API itself correctly enforces that only admins can change the image owner.

• Expected Behavior
  When a consumer accepts a shared image:

The member status should change from pending to accepted
The image owner should remain the original producer (tenantA in your case)
The image should remain visible to the original owner

• python-glanceclient Behavior
  I also checked python-glanceclient, and it does not have this issue because it uses separate commands:

glance image-update - for updating image properties only
glance member-update <image_id> <member_id> <status> - for updating member status only
Since these are separate commands, there's no ambiguity about whether --project should change ownership or just identify the member. The architecture properly separates concerns.

• Bug Report Information
  If you file a bug report, you can reference:
  Component: openstackclient / image v2
  File: openstackclient/image/v2/image.py, SetImage.take_action() method
  Issue: Lines 1396-1398 unconditionally set owner_id when --project is provided, even when used with membership flags