maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxxx>]

Hi, Adam!

On Sep 09, Adam M. Dutko wrote:
> > So, "Phone Home" or "MySQL feedback daemon" or "better name wanted"
> > feature.
> 
> Maybe call it "Butler"  ??? Just a thought...

:)
Why?
 
> > Not unlike the Uptimes Project or Debian Popularity Contest.
>
> Opt-in only with an easy disable option after opting in... correct?

Of course.

Sorry, I didn't make it clear enough - the first email was only about
questions, unclear moments in this task. Whether it should be opt-in is
not one of them :)
 
> > The complete specs will be here:
> > http://askmonty.org/worklog/Server-Sprint/?tid=12
> >
> I imagine the following ...
> 
>   (optionally by user) geographic location
>   (optionally by user) user information / company name
>   (optionally by user) Monty Program Ab customer support contract id
> 
> won't be shown to everyone, correct?  So maybe a filtered public
> versus unfiltered private view?

Of course.
 
> > 1. Should that be a MariaDB plugin or a separate executable ?
> >
> A separate executable would probably be the best for the reasons you
> highlight in your first paragraph.  The drawbacks are probably covered by
> the fact that 1) if a user is having that awful of a time, they are probably
> able to step through the executing code or 2) the user probably has a
> support contract with a company that can step through the code and debug the
> problem.  Granted more in depth statistics would be useful, but maybe it
> would make sense to have a separate project to create a loadable module that
> would be "more invasive."  This tool seems to be oriented towards usage and
> "usage related" data, not necessarily troubleshooting/fixing.

Right.
 
> > 2. How to send the data.
> >
> I imagine if the code is generated with this in mind it should be easy
> to switch out the "transport" (read transmission method) layer at a
> later time.  Unless the person coding it really ties the data
> formatting and submission process to the protocol.

Right.
 
> 3. Auditing.
> >
> I think the proxy idea, as well as the "wget mode" are great ideas.
> If the user isn't paranoid and doesn't want to "sniff traffic" one
> could also provide a log of all activities and a separate log for all
> messages.

Yes. I was trying to find something convincing for paranoid users (like
me :). Normal users can just look in the log.
 
> > 4. What to report.
> >
> >  hardware: CPU, RAM
> 
> maybe disk speeds? and type?  (SATA vs SAS vs IDE)

Good idea. Indeed, it's important.
And to know if it's SSD or not.
 
> >  OS (linux distribution, kernel)
> 
> any libraries?

I don't know.
As you said it's not to troubleshoot, it's to steer development.

I don't know if we may want to optimize for a specific version of a
specific library. And if yes - for what library?
 
> >  number of databases, max/avg number of tables in a database,
> >
> the slightly insane might also run multiple instances on a single
> machine, so what about checking for other installations?

Right.
 
> Just a few thoughts, hopefully they're not distracting or useless.

Not at all!
Thanks for sharing them.

Regards,
Sergei