Followup: weird behaviour with ceph osd pool create and the "crush-rule" parameter (suddenly changes behaviour)
So, whilst debugging the behaviour in the first thread I created, I needed to create and then destroy pools (to avoid running out of placement groups). So, I did something like: ceph osd pool create ec2pool 2048 2048 erasure glasgow-eci-test ec2pool 0 ceph osd pool create ec3pool 2048 2048 erasure glasgow-eci-test2 ec3pool 0 (for two different types of ecpool) and then removed them with ceph osd pool rm ec2pool ec2pool --yes-i-really-really-mean-it ceph osd pool rm ec3pool ec3pool --yes-i-really-really-mean-it Now, however, something seems to have broken, as if I attempt: ceph osd pool create ec4pool 2048 2048 erasure glasgow-eci-test3 ec4pool 0 it fails with Error ENOENT: specified rule ec4pool doesn't exist (which, of course, it does not, as the whole point of the syntax is that ceph should build the crush rule for me and name it appropriately; and this worked for all the previous times). ceph health returns HEALTH OK still. Any suggestions? I've googled around a bit on this, but I can't seem to find anyone discussing it... Sam
From memory if you specify a crush rule (even if it is the same as the pool name), it will look for a rule and error if it is not found, rather than creating it. The behaviour may have changed, but try explicitly not supplying a crush rule name (if you haven't already). Cheers, Tom -----Original Message----- From: aoanla@gmail.com <aoanla@gmail.com> Sent: 04 September 2019 14:43 To: ceph-users@ceph.io Subject: [ceph-users] Followup: weird behaviour with ceph osd pool create and the "crush-rule" parameter (suddenly changes behaviour) So, whilst debugging the behaviour in the first thread I created, I needed to create and then destroy pools (to avoid running out of placement groups). So, I did something like: ceph osd pool create ec2pool 2048 2048 erasure glasgow-eci-test ec2pool 0 ceph osd pool create ec3pool 2048 2048 erasure glasgow-eci-test2 ec3pool 0 (for two different types of ecpool) and then removed them with ceph osd pool rm ec2pool ec2pool --yes-i-really-really-mean-it ceph osd pool rm ec3pool ec3pool --yes-i-really-really-mean-it Now, however, something seems to have broken, as if I attempt: ceph osd pool create ec4pool 2048 2048 erasure glasgow-eci-test3 ec4pool 0 it fails with Error ENOENT: specified rule ec4pool doesn't exist (which, of course, it does not, as the whole point of the syntax is that ceph should build the crush rule for me and name it appropriately; and this worked for all the previous times). ceph health returns HEALTH OK still. Any suggestions? I've googled around a bit on this, but I can't seem to find anyone discussing it... Sam _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Thanks for the suggestion, however... As noted above: the previous invocations of ceph osd pool create have exactly the same structure (and succeeded) as the one which fails. I used the long form because trying to use the short form (ceph osd pool create ec2pool 2048 2048 erasure glasgow-eci-test, for example) produced other "fatal" errors [complaining about my not specifying the final numeric positional parameter, even though it's optional]. Weirdly, though, you're right: going back to the short form suddenly works again... so I'd like to revise my question to: "why is the behaviour (and requirements) of ceph osd pool create inconsistent - sometimes failing if you don't specify all the parameters, even optional ones, and sometimes failing if you do, despite the 'rules' you're following being the same?"
Hi, just a short note on automatic rule creation. A SUSE engineer pointed me to the fact that this is actually documented [1] in the pool creation section, under [crush-rule-name] it says:
For replicated pools it is the rule specified by the osd pool default crush rule config variable. This rule must exist. For erasure pools it is erasure-code if the default erasure code profile is used or {pool-name} otherwise. This rule will be created implicitly if it doesn’t exist already.
I can't say anything about the inconsistency though, have you checked the logs for hints? Regards, Eugen [1] https://docs.ceph.com/docs/master/rados/operations/pools/#create-a-pool Zitat von aoanla@gmail.com:
Thanks for the suggestion, however...
As noted above: the previous invocations of ceph osd pool create have exactly the same structure (and succeeded) as the one which fails. I used the long form because trying to use the short form
(ceph osd pool create ec2pool 2048 2048 erasure glasgow-eci-test, for example)
produced other "fatal" errors [complaining about my not specifying the final numeric positional parameter, even though it's optional].
Weirdly, though, you're right: going back to the short form suddenly works again...
so I'd like to revise my question to:
"why is the behaviour (and requirements) of ceph osd pool create inconsistent - sometimes failing if you don't specify all the parameters, even optional ones, and sometimes failing if you do, despite the 'rules' you're following being the same?" _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
As far as I could tell, there wasn't anything in the logs (at the default log levels), other than the forwarded request to the mons... (I did read the documentation, which is why I was using the long form... it's the inconsistency which is problematic, especially since it also happens if you repeat an earlier form of the command identically - sometimes it needs long form, sometimes short form.)
On Thu, Sep 5, 2019 at 2:12 AM <aoanla@gmail.com> wrote:
As far as I could tell, there wasn't anything in the logs (at the default log levels), other than the forwarded request to the mons...
(I did read the documentation, which is why I was using the long form... it's the inconsistency which is problematic, especially since it also happens if you repeat an earlier form of the command identically - sometimes it needs long form, sometimes short form.)
Does it create a profile the first time it is run, then the second time sees that a profile exists and wants you to specify it since it can't create a profile of the same name?
Nice thought but no: in the case in the original post "ec4pool" had not been used as the name for a pool, or a profile, before. (and trying out combinations of deleting old profiles did not change the behavior).
participants (4)
-
aoanla＠gmail.com
-
Eugen Block
-
Robert LeBlanc
-
Thomas Byrne - UKRI STFC