No error handling for adding same volume multiple times to the same group.

Bug #1665555 reported by lucky
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Cinder
Low
Mutya Sai Phanindra

Bug Description

Step 1 : add a existing to a group:

cinder --os-volume-api-version 3.13 group-update --add-volumes d5db026a-4f18-46f4-bd7c-47d429e8fdca c94eb645-a9a9-4aef-a0c3-492f30d8edcb

**** no output, however volume is successfully added to the group*******

Step 2 : Now, add two volumes to the same group, provided first volume is same as above and second is new.

cinder --os-volume-api-version 3.13 group-update --add-volumes d5db026a-4f18-46f4-bd7c-47d429e8fdca,8b981673-b0a0-437b-8614-fa485a979d59 c94eb645-a9a9-4aef-a0c3-492f30d8edcb

***** No output, second volume is successfully added to the group ****** However, no error at user end that d5db026a-4f18-46f4-bd7c-47d429e8fdca is already added to the given group_id.

ideally, it must generate an error for first volume along with successful message for addition of second volume.

lucky (luckysingh)
summary: - No error for adding same volume multiple times to the same group.
+ No error handling for adding same volume multiple times to the same
+ group.
Changed in python-cinderclient:
assignee: nobody → Dinesh Bhor (dinesh-bhor)
Changed in python-cinderclient:
status: New → Confirmed
Revision history for this message
Pooja Jadhav (poojajadhav) wrote :

Hi All,

I have come across a scenario where if user adds two volumes to volume group of which one is already added in the group then it adds 2nd volume to the group and returns 202 response to the user,
but when user tries to add two volumes to volume group which were already added then in that case it returns 400 Bad Request.
IMO to maintain the consistency in API behavior, it should return 400 HTTPBadRequest instead of 202 for the case where user tries to add two volumes out of which one is already added to volume group.

Please let me know your suggestion about the same.

Scenario 1:
If both volumes are already added to the group then it returns 400 Bad Request.

cinder --os-volume-api-version 3.13 group-update --add-volumes be543c8f-a779-4b4e-b1e1-9b611a410a50,6ce9f6af-2d0b-4d36-8d7b-bdc542f0c164 df6b9470-4cdd-422a-bea1-c5c80d84fbdb

ERROR: Invalid Group: Cannot update group df6b9470-4cdd-422a-bea1-c5c80d84fbdb because no valid name, description, add_volumes, or remove_volumes were provided. (HTTP 400)

Scenario 2:
If first volume already added and the second one is new to be added to the group, cinder service ignores the first volume as it is already added and it adds the second volume to the group giving 202 response to the user. Is it an expected behavior?

cinder --os-volume-api-version 3.13 group-update --add-volumes be543c8f-a779-4b4e-b1e1-9b611a410a50,6ce9f6af-2d0b-4d36-8d7b-bdc542f0c164 df6b9470-4cdd-422a-bea1-c5c80d84fbdb

202 Accepted

IMO with taking API consistency with the [1] scenario, it should return 400 HTTPBadRequest for the first volume as it is already added.

Changed in python-cinderclient:
assignee: Dinesh Bhor (dinesh-bhor) → Pooja Jadhav (poojajadhav)
Xing Yang (xing-yang)
affects: python-cinderclient → cinder
Revision history for this message
Xing Yang (xing-yang) wrote :

Senario 1 should be consistent with scenario 2. If volumes are already part of the group that they are being added to, it should return success. A INFO message in the log will be helpful if a volume to be added to a group is already in the group.

Xing Yang (xing-yang)
Changed in cinder:
importance: Undecided → Low
tags: added: groups
Revision history for this message
Pooja Jadhav (poojajadhav) wrote :

Hi Xing,

When a volume is added in a group, its 'updated_at' field gets updated. So if user tries to add 2 volumes of which one volume is already exist in the group, then it will be skipped and its ‘updated_at’ field will not be updated. As per your suggestion if we return HTTP 202 and later user requests recently updated volumes then this volume might be skipped as its updated time is old which results in providing incorrect information to the user.

So IMO we should raise BadRequest for such situations.
Please let me know your suggestion about the same.

Revision history for this message
Xing Yang (xing-yang) wrote :

Hi Pooja,

If a volume is already attached when attaching a volume, we don't error out and just return success. If a volume is already deleted when deleting a volume, we don't error out and just return success. Similarly here when a volume is already added to a group, we don't error out and just return success.

I don't see the value of checking updated volumes by timestamp to find what volumes are added to a group. Users want to know whether volumes are in a group or not. They can get that by viewing the details of a group. They can also find out whether a volume belongs to a group or not by viewing the volume details.

Revision history for this message
jiamin (shljia) wrote :

Hi all,

let me add Scenario 3, when I add a volume which has been in the group again, the error message is not so obvious to me.

$ cinder group-update --add-volumes 35bbdd05-d72c-43c8-89ad-3fed608fc333 13f31c7f-ed5b-42c8- ac2c-6275cea46b5b
ERROR: Invalid Group: Cannot update group 13f31c7f-ed5b-42c8-ac2c-6275cea46b5b because no valid name, description, add_volumes, or remove_volumes were provided. (HTTP 400) (Request-ID: req-9560b4d1-e444-4714-b11e-6becc13af1f1)

is it better to show something like this, or just do nothing and return success?

$ cinder group-update --add-volumes 35bbdd05-d72c-43c8-89ad-3fed608fc333 13f31c7f-ed5b-42c8-ac2c-6275cea46b5b
ERROR: Invalid Group: Cannot add volume 35bbdd05-d72c-43c8-89ad-3fed608fc333 to group 13f31c7f-ed5b-42c8-ac2c-6275cea46b5b because it is already in group 13f31c7f-ed5b-42c8-ac2c-6275cea46b5b. (HTTP 400) (Request-ID: req-9560b4d1-e444-4714-b11e-6becc13af1f1)

Revision history for this message
Sean McGinnis (sean-mcginnis) wrote : Bug Assignee Expired

Unassigning due to no activity for > 6 months.

Changed in cinder:
assignee: Pooja Jadhav (poojajadhav) → nobody
Changed in cinder:
assignee: nobody → Mutya Sai Phanindra (phani8179)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers