On Mon, 08 Dec 2014 08:33:25 -0600 Mark Nelson wrote: > I've been thinking for a while that we need another more general command > than Ceph health to more generally inform you about your cluster. IE I > personally don't like having min/max PG warnings in Ceph health (they > can be independently controlled by ceph.conf options but that kind of > approach won't scale). I'd like another command that I can run that > tells me about this kind of thing. Same thing with experimental > features. I don't want ceph health warning me if they've been enabled, > but I do want to know if they've ever been enabled, when, and whether > they are still in effect. > Very much agreed. Expanding on this, setting a cluster to no-scrub will result in a warning (very arguably) and while a slow request after 30 seconds is WRN worthy, after something like a minute it ought to be ERR level as this is likely to have massive impact on clients. Christian > Mark > > On 12/08/2014 06:57 AM, Fred Yang wrote: > > You will have to consider in the real world whoever built the cluster > > might not document the dangerous option to let support stuff or > > successor aware. Thus any experimental feature considered not safe for > > production should be included in a warning message in 'ceph health', > > and logs, either log it periodically or log the warning msg upon > > restart. Feature-wise, 'ceph health detail' should give you a report > > over all important features/options of the cluster as well. > > > > -Fred > > > > On Sun, Dec 7, 2014, 11:15 PM Justin Erenkrantz <justin@xxxxxxxxxxxxxx > > <mailto:justin@xxxxxxxxxxxxxx>> wrote: > > > > On Fri, Dec 5, 2014 at 12:46 PM, Mark Nelson > > <mark.nelson@xxxxxxxxxxx <mailto:mark.nelson@xxxxxxxxxxx>> wrote: > > > I'm in favor of the "allow experimental features" but instead > > call it: > > > > > > "ALLOW UNRECOVERABLE DATA CORRUPTING FEATURES" which makes > > > things > > a little > > > more explicit. With great power comes great responsibility. > > > > +1. > > > > For Subversion, we utilize SVN_I_LOVE_CORRUPTED_XXX for a few > > options that can cause data corruption. -- justin > > -- > > To unsubscribe from this list: send the line "unsubscribe > > ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx > > <mailto:majordomo@xxxxxxxxxxxxxxx> > > More majordomo info at http://vger.kernel.org/__majordomo-info.html > > <http://vger.kernel.org/majordomo-info.html> > > > _______________________________________________ > ceph-users mailing list > ceph-users@xxxxxxxxxxxxxx > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > -- Christian Balzer Network/Systems Engineer chibi@xxxxxxx Global OnLine Japan/Fusion Communications http://www.gol.com/ -- 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
