Bug 1312242 - Pool creation with duplicate name from two session succeeds but creates only one in backend
Summary: Pool creation with duplicate name from two session succeeds but creates only ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Ceph Storage
Classification: Red Hat Storage
Component: Calamari
Version: 2.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: 2.3
Assignee: Christina Meno
QA Contact: ceph-qe-bugs
URL:
Whiteboard:
Depends On:
Blocks: 1291304 1353583
TreeView+ depends on / blocked
 
Reported: 2016-02-26 08:43 UTC by Shubhendu Tripathi
Modified: 2022-02-21 18:06 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-31 15:50:27 UTC
Embargoed:


Attachments (Terms of Use)

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.


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