Re: v0.38 released

[Andre Noll <maan@systemlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 3843 bytes --]

On Fri, Nov 18, 10:47, Tommi Virtanen wrote:
> On Fri, Nov 18, 2011 at 07:01, Andre Noll <maan@systemlinux.org> wrote:
> > For starters, it would be nice to include the ceph osd subcommands
> > in the man pages. To my knowledge they are only documented on the
> > (old) wiki
> >
> >        http://ceph.newdream.net/wiki/Monitor_commands
> >
> > at the moment. Would a patch that adds the subcommands and descriptions
> > to the man pages be accepted?
> 
> I'm not sure if the man page are the best for that; there's a lot of
> subcommands, and man forces it into a big list of things. I'd
> personally go for putting a reference under
> http://ceph.newdream.net/docs/latest/ops/ and using the structure for
> separating osd/mon/mds etc into slightly more manageable chunks.

I believe that code and documentation should be located as close as
possible, and I'd also prefer to edit and access the documentation
locally via command line tools rather than through a browser. But
I don't have a strong opinion on this, so let's go for the web
documentation.

Should I prepare something and post a request for inclusion to the
web pages on this mailing list, or do you want me to edit the web
documentation directly?

> > If so, I'd be willing to do this work. However, the files in man/
> > of the ceph git repo seem to be generated by docutils, so I suspect
> > they are not meant to be edited directly. What's the preferred way
> > to patch the man pages?
> 
> The content comes from doc/man/ and is built with ./admin/build-doc
> 
> That puts the whole html into build-doc/output/html/ and the *roff in
> build-doc/output/man/ and from there it is migrated to man/ "by need"
> (there's too much noise in the changes to keep doing that all the
> time, and there's too many toolchain dependencies to generate docs on
> every build).

I see, thanks for explaining. The ./admin/build-doc command worked
for me out of the box on an Ubuntu lucid system btw.

> >> Step 2: have a monitoring system be able to feed back information to
> >> use as osd weights, with admin customazability
> > How could such a monitoring system be implemented? In particular if
> > abstract criteria like "future extension plans" have to be considered.
> 
> Going back to my initial list: storage size, disk IO speed, network
> link bandwidth, heat in that
> part of the data center, future expansion plans, ..
> 
> That divides into 3 groups:
> - things that are more about the capability of the hardware (= change
> very seldomly)
> - things that are monitored outside of ceph
> - plans
> 
> Hence, it seems to me that a sysadmin would do something like look at
> the node data gathered by something like Ohai/Chef, combine that with
> collectd/munin-style monitoring of the data center, optionally do
> something like "increase weights of rack 7 by 40%", and then spit out
> a mapping of osd id -> weight.

OK, got the idea. However, in this example the difficult thing is
the decision "increase weights of rack 7 by 40%", which is made by a
human. Recomputing the osd weights accordingly should be fairly simple.

> Our chef cookbooks will probably provide a skeleton for that in the
> future, but that's not a short term need; most installations will
> probably set the weights once when the hardware is new, and I'd expect
> practically all clusters <6 months old to have fairly homogenous
> hardware, and thus identical weights.

Are you implying that ceph is only suitable for new clusters with
homogeneous hardware? I'm asking because our cluster is far from
homogeneous. There are 8 year old 2-core nodes with small SCSI disks
as well as 64-core boxes with much larger SATA disks.

Thanks
Andre
-- 
The only person who always got his work done by Friday was Robinson Crusoe

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]