Image member duplicates should be constrained by the db layr
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Glance |
Triaged
|
Low
|
Raildo Mascena de Sousa Filho |
Bug Description
This is related to bug https:/
Previously, image members could be created more than once, causing duplicates. The current solution to this is doing a check when creating a member to see if it already exists. This does not handle duplicates that already exist. Also, if the db instead had constraints to not allow duplicates we could remove the extra db call and future version of the api and other places where this check may be needed will inherit the constraint.
A fix for this will need to include a migration to handle duplicate image members. This could be tricky since any updates to a member may cause the duplicates to diverge. For example, updating status of a member when there are duplicates only sets one members status to 'accepted'.
Changed in glance: | |
status: | New → Triaged |
Changed in glance: | |
assignee: | nobody → Lee Li (lilinguo) |
Changed in glance: | |
assignee: | Lee Li (lilinguo) → nobody |
Changed in glance: | |
assignee: | nobody → Raildo Mascena de Sousa Filho (raildo) |
After analyzing, I noticed that bug #1255607 this get call is unnecessary. /github. com/openstack/ glance/ blob/master/ glance/ db/__init_ _.py#L236
https:/
But after looking deeper at the code, I realized that create_member /github. com/openstack/ glance/ blob/master/ glance/ db/sqlalchemy/ api.py# L956 /github. com/openstack/ glance/ blob/master/ glance/ db/sqlalchemy/ api.py# L976
https:/
and update_member
https:/
are routed to the same call: /github. com/openstack/ glance/ blob/master/ glance/ db/sqlalchemy/ api.py# L984
https:/
So there will never be a duplicate query, as if the member does not exist it creates a new one, if the member exists it is an update, so the constrain to deny duplication that exists but will never be used. /github. com/openstack/ glance/ blob/master/ glance/ db/sqlalchemy/ models. py#L198
https:/
In short I believe we have two solutions:
1 - just remove the get, because with the current implementation it is never duplicated in the table, however the functionality of create and update member are the same, which it seems is conceptually wrong.
2- create a different call from member-create in the API and in the client where will be done an insert in the table "image_members" and the treatment will be done to deny duplicate and create a new call member-update that will be an update on the table.