+1 for a separate jar (and a second download link that doesn't include this jar, though I would make the primary link include it with BIG BOLD PRINT saying it is in there) +1 for a config option to turn off auto-post (defaulted on in the download that has the jar) +1 for a nodetool command to dump it to a file for manual posting
I think this could be a good debugging tool as well. Have a command to dump "here is what my cluster looks like" to a file, that could then be sent though email for others to be used help resolve issues with would be nice. The current nodetool information commands have too much stuff that needs to be sanitized out before you can send it outside the firewall. - Jeremiah On Nov 16, 2011, at 7:16 PM, Jeremy Hanna wrote: > Sounds like it would be best if it were in a separate jar for people? > > On Nov 16, 2011, at 4:58 PM, Bill wrote: > >>> Thoughts? >>> >> >> We'll turn this off, and would possibly patch it out of the code. That's not >> to say it wouldn't be useful to others. >> >> Bill >> >> >> On 15/11/11 23:23, Jonathan Ellis wrote: >>> I started a "users survey" thread over on the users list (replies are >>> still trickling in), but as useful as that is, I'd like to get >>> feedback that is more quantitative and with a broader base. This will >>> let us prioritize our development efforts to better address what >>> people are actually using it for, with less guesswork. For instance: >>> we put a lot of effort into compression for 1.0.0; if it turned out >>> that only 1% of 1.0.x users actually enable compression, then it means >>> that we should spend less effort fine-tuning that moving forward, and >>> use the energy elsewhere. >>> >>> (Of course it could also mean that we did a terrible job getting the >>> word out about new features and explaining how to use them, but either >>> way, it would be good to know!) >>> >>> I propose adding a basic cluster reporting feature to cassandra.yaml, >>> enabled by default. It would send anonymous information about your >>> cluster to an apache.org VM. Information like, number (but not names) >>> of keyspaces and columnfamilies, ks-level options like compression, cf >>> options like compaction strategy, data types (again, not names) of >>> columns, average row size (or better: the histogram data), and average >>> sstables per read. >>> >>> Thoughts? >>> >> >> >
