Bug 1341598 - Crush rule ids are not set as specified in the request instead takes the auto incremented one [NEEDINFO]
Summary: Crush rule ids are not set as specified in the request instead takes the auto...
Alias: None
Product: Red Hat Ceph Storage
Classification: Red Hat
Component: Calamari
Version: 2.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: 2.0
Assignee: Christina Meno
QA Contact: Nishanth Thomas
Depends On:
Blocks: 1339529 1343229
TreeView+ depends on / blocked
Reported: 2016-06-01 10:32 UTC by Nishanth Thomas
Modified: 2016-08-23 19:40 UTC (History)
5 users (show)

Fixed In Version: calamari-server-1.4.1-1.el7cp
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2016-08-23 19:40:20 UTC
Target Upstream Version:
gmeno: needinfo? (nthomas)

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:1755 0 normal SHIPPED_LIVE Red Hat Ceph Storage 2.0 bug fix and enhancement update 2016-08-23 23:23:52 UTC

Description Nishanth Thomas 2016-06-01 10:32:55 UTC
Description of problem:
Crush rule ids are not set as specified in the request instead takes the auto incremented one. The issue here is that the crush rule created becomes unusable

Expected results:
Make it auto incremented by default. User need not specify crush rule id in the crush rule creation request

Comment 2 Christina Meno 2016-06-02 15:36:14 UTC
the workaround is hard, USM has to guess what ceph will assign the ruleset id
one possibility is to relax the validation so that ruleset is not required on create

Comment 3 Nishanth Thomas 2016-06-04 10:40:16 UTC
I think that would be sufficient. Let the ruleset is autogenerated, which will solve the problem for us. The only thing to make sure is that, calamari gets the right ruleset and stores it.

Comment 4 Christina Meno 2016-06-08 22:57:31 UTC
I'm a little confused here:
ruleset has not been required in create or update since 5/18/16.

Nishanth is it that you want them to not be allowed during create or update since we don't honor them?

Comment 7 Harish NV Rao 2016-07-12 10:31:30 UTC
Moving this to verified state as Nishanth confirmed that the issue is fixed.

Comment 9 errata-xmlrpc 2016-08-23 19:40:20 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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