Image member duplicates should be constrained by the db layr

Bug #1255607 reported by Alex Meade
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Raildo Mascena de Sousa Filho

Bug Description

This is related to bug

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'.

Feilong Wang (flwang)
Changed in glance:
status: New → Triaged
Lee Li (lilinguo)
Changed in glance:
assignee: nobody → Lee Li (lilinguo)
Lee Li (lilinguo)
Changed in glance:
assignee: Lee Li (lilinguo) → nobody
Changed in glance:
assignee: nobody → Raildo Mascena de Sousa Filho (raildo)
Revision history for this message
Raildo Mascena de Sousa Filho (raildo) wrote :

After analyzing, I noticed that bug #1255607 this get call is unnecessary.

But after looking deeper at the code, I realized that create_member
and update_member

are routed to the same call:

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.

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.

Revision history for this message
Vincent Legoll (vincent-legoll) wrote :

Please, do not forget migrations from previous versions where duplicated entries may already exist in the DB at upgrade time.

Sites with old OpenStack version exist and should not endure painful migrations where the DB gets more and more "corrupted" or in an inconsistent state when at the same time the new code is assuming more and more consistency from the DB data.

Seat belts + brakes + helmet + airbag + etc...

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers