Bug 1312242

Summary: Pool creation with duplicate name from two session succeeds but creates only one in backend
Product: [Red Hat Storage] Red Hat Ceph Storage Reporter: Shubhendu Tripathi <shtripat>
Component: CalamariAssignee: Christina Meno <gmeno>
Calamari sub component: Back-end QA Contact: ceph-qe-bugs <ceph-qe-bugs>
Status: CLOSED WONTFIX Docs Contact:
Severity: medium    
Priority: unspecified CC: ceph-eng-bugs, kdreyer, ltrilety, mkudlej
Version: 2.0   
Target Milestone: rc   
Target Release: 2.3   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-03-31 15:50:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1291304, 1353583    

Description Shubhendu Tripathi 2016-02-26 08:43:22 UTC
Description of problem:
When we submit pool creation request with same name from two browser session simultaneously, both the requests are successful from calamari side.

But while verifying in backend we can see only one pool created.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Create a ceph cluster
2. From two browser session, send pool creation request simultaneously
3. Both the requests are successful
4. Verify in ceph backend from mon node. Only one pool is created

Actual results:
Pool creation with same name allowed from two different session.

Expected results:
Pool creation with same name should not be allowed.

Additional info:

Comment 2 Christina Meno 2016-05-06 04:16:39 UTC
There's really no good way to fix what you're reporting.

creating a pool is an http://calamari.readthedocs.io/en/latest/calamari_rest/conventions.html#asynchronous-operations

HTTP 202 only says that we've accepted your request

The real status is a http://calamari.readthedocs.io/en/latest/calamari_rest/resources/resources.html#requestviewset based on the request_id that you get back as part of the async

Comment 3 Shubhendu Tripathi 2016-05-06 04:21:12 UTC
@Gregory, I accept that both the requests are submitted and return status as 202.
But the /api/v2/request/<id> return "completed" for both the tasks and errorMessage as well is blank for both of them.

Thats an issue. At least one of the tasks should report an error.

Comment 4 Shubhendu Tripathi 2016-07-08 07:46:05 UTC
Moving back to assigned state as QE also reported this as an issue at BZ#1353583.
Not a blocker for RHS-C 2.0 though :)

Comment 5 Martin Kudlej 2016-07-08 07:57:33 UTC
I agree with Shubhendu that second task should return error message and it should failed. 
Imagine that one user try to create pool with different setup than other one. Pool with which setup will be created?
I think 1st task from user 1 who has 1st submitted creating of "poolX" should pass.
2nd task from user 2 who has submitted creating of "poolX" after user 1 should fail with proper error message.
Please see bug 1353583.
--> Reopen

Comment 6 Lubos Trilety 2017-04-03 06:50:48 UTC
Seems to me that WONTFIX is more appropriate in this case.