Red Hat Bugzilla – Bug 1312242
Pool creation with duplicate name from two session succeeds but creates only one in backend
Last modified: 2017-04-03 02:50:48 EDT
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):
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
Pool creation with same name allowed from two different session.
Pool creation with same name should not be allowed.
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
@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.
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 :)
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.
Seems to me that WONTFIX is more appropriate in this case.