On Mon, Nov 28, 2011 at 06:04, Andre Noll <maan@xxxxxxxxxxxxxxx> wrote:
> Here is what I have so far. This patch set imports the documentation
> of the OSD subcommands from the wiki to the preciously emtpy file
> doc/ops/monitor.rst of the git repo. The first patch is just the
> result of a cut & paste operation of the corresponding wiki page
> while the other patches try to improve on this. The aim is to have
> a complete and up to date documentation for all osd subcommands.
>
> I don't believe the series is ready for inclusion yet as some
> subcommands (cluster_snap, lost, in, out, ...) still lack useful
> descriptions. It would be nice to add one sentence to each such command
> that explains its purpose and the circumstances under which one might
> want to use this particular command.
>
> So please review and comment. I will fold in your suggestions and
> follow up with a re-rolled series provided there is substantial
> feedback.
Good work! I want to roll this in the docs asap, even if it is still partial.
For that to happen, we need to do two things:
1. get you to add Signed-off-by lines as per SubmittingPatches
2. figure out where this documentation belongs
For ops/monitor is meant for "how do I reassure myself my service
works the right way". Think nagios, collectd, munin, etc. Apologies
for not having much content there yet..
The ops/ hierarchy as a whole is meant to be "user/goal oriented".
That is, I don't want to put in a section "ceph monitor commands".
Instead, we need to ask the question "what is the admin trying to do",
and that's the guiding principle for ops/.
A reference-style document that exhaustively lists all possible
actions should go into some other top-level section. Right now, the
closest parallels we have are config/ ("Configuration reference") and
api/, both meant to be comprehensive references.
Let's do this: make your patch put things in doc/control.rst, with the
title "Control commands", and have doc/index.rst toctree have, below
config, an entry for control. I can take it from there if we want to
reorganize the document more.
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
