Bug 1312242 - Pool creation with duplicate name from two session succeeds but creates only one in backend
Pool creation with duplicate name from two session succeeds but creates only ...
Product: Red Hat Ceph Storage
Classification: Red Hat
Component: Calamari (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: 2.3
Assigned To: Gregory Meno
Depends On:
Blocks: 1291304 1353583
  Show dependency treegraph
Reported: 2016-02-26 03:43 EST by Shubhendu Tripathi
Modified: 2017-04-03 02:50 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-03-31 11:50:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Shubhendu Tripathi 2016-02-26 03:43:22 EST
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:

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 Gregory Meno 2016-05-06 00:16:39 EDT
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 00:21:12 EDT
@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 03:46:05 EDT
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 03:57:33 EDT
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 02:50:48 EDT
Seems to me that WONTFIX is more appropriate in this case.

Note You need to log in before you can comment on or make changes to this bug.