Image member duplicates should be constrained by the db layr

[Alex Meade]

This is related to bug https://bugs.launchpad.net/glance/+bug/1231485

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

[Raildo Mascena de Sousa Filho (raildo)]

After analyzing, I noticed that bug #1255607 this get call is unnecessary.
https://github.com/openstack/glance/blob/master/glance/db/__init__.py#L236

But after looking deeper at the code, I realized that create_member
https://github.com/openstack/glance/blob/master/glance/db/sqlalchemy/api.py#L956
and update_member
https://github.com/openstack/glance/blob/master/glance/db/sqlalchemy/api.py#L976

are routed to the same call:
https://github.com/openstack/glance/blob/master/glance/db/sqlalchemy/api.py#L984

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.
https://github.com/openstack/glance/blob/master/glance/db/sqlalchemy/models.py#L198

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.

[Vincent Legoll (vincent-legoll)]

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