On Thu, 25 Jul 2019, Ernesto Puerta wrote: > I'd add this one to the wish-list: > > - Configuration settings (out of the >1500 available) diverging from their > defaults (sensitive ones redacted). https://github.com/ceph/ceph/pull/29334 ? sage > > Kind regards, > Ernesto > > > > > On Thu, Jul 25, 2019 at 5:55 PM Sage Weil <sage@xxxxxxxxxxxx> wrote: > > > On Thu, 25 Jul 2019, Lars Marowsky-Bree wrote: > > > Hi all, > > > > > > I've had a chat with Sage & Dan Mick about the current state of > > > telemetry, and I'd like to propose a few ideas to hopefully improve it > > > and make the data collected more relevant. > > > > > > The current data is quite limited. I was able to take a look at, say, > > > how many pools out there (well, of the ~300ish clusters that ever > > > reported) have a non-2^n pg_num, but seeing whether this affects > > > performance or data distribution was not possible. > > > > > > My goal is to have telemetry data that allows us to make more informed > > > decisions about what matters to the user base; the comments below are > > > not necessarily ordered by relevance, since they grew out of a thread on > > > looking at the current data reported. > > > > > > Curious about your thoughts - too detailed information? Anything you'd > > > like to see included? What'd help you in your area? > > > > > > - The crash section does expose actual hostnames ("entity_name"). If we > > > want to preserve that we can see whether it's the same entity crashing > > > or another, I'd propose that, similar to report_id, we generate a > > > report_secret_salt in the plugin that we don't share with the server - > > > we can then use this to hash any potential strings consistently. > > > > +1. This is high priority.. we need to get it into the next nautilus point > > release, update the endpoint to scrub new reports, and scrub all existing > > data. > > > > > (This will change with Sage's pending PR to point this at a different > > > channel.) > > > > For reference, https://github.com/ceph/ceph/pull/28847. I think this is > > ready for review. > > > > > [...] > > > > All of this sounds nice to have... probably one item per PR to add the new > > info. > > > > > - I'd pull contact/organization/description into a separate section and > > > channel. We'll need to also document what this information is used > > > for. > > > > This is added to my open PR above. > > > > > I'm wondering what the best way of tracking all wishes and then deciding > > > on which to fulfil is. > > > > Trello? :) > > > > sage > > _______________________________________________ > > Dev mailing list -- dev@xxxxxxx > > To unsubscribe send an email to dev-leave@xxxxxxx > > > _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx