From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Noll Subject: Re: v0.38 released Date: Mon, 21 Nov 2011 18:32:54 +0100 Message-ID: <20111121173254.GN13394@systemlinux.org> References: <20111115164254.GJ13394@systemlinux.org> <20111116095614.GK13394@systemlinux.org> <20111117103524.GL13394@systemlinux.org> <20111118150157.GM13394@systemlinux.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+2GlJm56SCtLHYlr" Return-path: Received: from systemlinux.org ([79.140.41.46]:33673 "EHLO v3-1046.systemlinux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755324Ab1KURbF (ORCPT ); Mon, 21 Nov 2011 12:31:05 -0500 Content-Disposition: inline In-Reply-To: Sender: ceph-devel-owner@vger.kernel.org List-ID: To: Tommi Virtanen Cc: Gregory Farnum , Sage Weil , ceph-devel@vger.kernel.org --+2GlJm56SCtLHYlr Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 18, 10:47, Tommi Virtanen wrote: > On Fri, Nov 18, 2011 at 07:01, Andre Noll 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 > > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0http://ceph.newdream.net/wiki/Monitor_comman= ds > > > > at the moment. Would a patch that adds the subcommands and descriptions > > to the man pages be accepted? >=20 > 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? >=20 > The content comes from doc/man/ and is built with ./admin/build-doc >=20 > 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. >=20 > 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, .. >=20 > That divides into 3 groups: > - things that are more about the capability of the hardware (=3D change > very seldomly) > - things that are monitored outside of ceph > - plans >=20 > 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 --=20 The only person who always got his work done by Friday was Robinson Crusoe --+2GlJm56SCtLHYlr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk7Ki0YACgkQWto1QDEAkw8KTwCgiFeIyle6nCR0C+6e+F18K8RJ mUUAnRHdJoM0sO3hN7fH8kMr/dDijxDy =jLMt -----END PGP SIGNATURE----- --+2GlJm56SCtLHYlr--