Bug #20057
openceph-osd: some flags are not documented in the help output
0%
Description
I was trying to find about a few options on some flags I saw while deploying an OSD and they didn't come up when running `ceph-osd --help`:
- --mkkey
- --monmap
- --osd-uuid
- --keyring
ceph version 11.2.0 (f223e27eeb35991352ebc1f67423d4ebc252adb7)
These flags are consumed by ceph-disk, for example in this output:
[node2][WARNIN] activate: OSD id is 1 [node2][WARNIN] activate: Initializing OSD... [node2][WARNIN] command_check_call: Running command: /usr/bin/ceph --cluster ceph --name client.bootstrap-osd --keyring /var/lib/ceph/bootstrap-osd/ceph.keyring mon getmap -o /home/vagrant/osd/activate.monmap [node2][WARNIN] got monmap epoch 2 [node2][WARNIN] command: Running command: /usr/bin/timeout 300 ceph-osd --cluster ceph --mkfs --mkkey -i 1 --monmap /home/vagrant/osd/activate.monmap --osd-data /home/vagrant/osd --osd-journal /home/vagrant/osd/journal --osd-uuid 8d208665-89ae-4733-8888-5d3bfbeeec6c --keyring /home/vagrant/osd/keyring --setuser ceph --setgroup ceph
Updated by Ken Dreyer almost 7 years ago
Similar issue with the man page, in #19879
Updated by Sameer Tiwari almost 7 years ago
As first time contributor, I am working on this issue.
Updated by Sameer Tiwari almost 7 years ago
Sameer Tiwari wrote:
As first time contributor, I am working on this issue.
As of the master branch 12.02, the 3 options do not exist in the ceph_osd.cc file anymore
--monmap --osd-uuid --keyring.
I am updated the missing --mkkey in the code
Updated by Sameer Tiwari almost 7 years ago
Just created a pull request, I hope I did it right.
https://github.com/stiwari/ceph/commit/a4754b8272c9c26a420909cf0e166cafe51dc09e
Updated by Sameer Tiwari almost 7 years ago
Updated by Alfredo Deza almost 7 years ago
- Status changed from Resolved to 12
I am a bit confused, not sure why some options are no longer in ceph_osd.cc (I guess these are inherited somehow then?) but the ticket should remain open,
because the "ceph-osd" CLI tool is accepting flags that are not documented.
The end user should not need to be aware where the flags are coming from. But if they are available and they can be used, they should be documented in the output.
Updated by Greg Farnum almost 7 years ago
Hmm, part of the problem is that these options are generically available as members of config_opts, but they take on particular importance when formatting an OSD. We don't have any defined way of inheriting option descriptions or specifying which ones we want to list -- because we definitely don't want to specify all the many hundreds of them in every help text!
So either we need to do it individually in the OSD even though the options aren't specified there, or we need some kind of new framework. Hmm...