Hardware analysis tool (was Metrics: RFC)

[Greg Dekoenigsberg]

So everyone agrees that this is a fabulous idea.  Is there a concrete 
proposal ready to fall out of it -- something that we can hand to someone 
and say "hey, do this"?

Here's what we've already got, and have had for ages:

* the client-side bits that harvest the hardware data.  They come from the 
up2date/rhn_register client... which is, yaaay! open source.  Back in the 
day, this code was based on kudzu, and now I guess it's based on lshal. 
RHN basically formats this data and sends it via xmlrpc to RHN servers -- 
where, near as I can tell, it sits uselessly because no one has time to 
analyze the data.

Here's what we need to get started:

* A dead simple client.  Maybe based on the RHN codebase, maybe not. 
Basically: "did your system work like a charm out of the box?  Click A. 
Not so much?  Click B."  Format the data, send it up via xmlrpc, all done, 
thanks so much.

* A dead simple xmlrpc server in the fp.o infrastructure that pulls this 
data and "does something with it".  Probably the best thing is just to 
shove it into mysql.

* A simple way of reporting on this data and making it visible.  Generate 
a list of hardware and rank each item with a ratio of "found in good 
configurations" versus "found in bad configurations".  The items at the 
top of the list will likely be the best.  The items at the bottom of the 
list will likely be the worst.

Really And For True, to get to version 0.1 of this beast is Not Much Work. 
What's required is someone who knows a little xmlrpc, a little sql, and 
is willing to take ownership of it.

Perhaps this is a good thing to work on at our first-ever Fedora Hackfest, 
to be announced Real Soon Now (tm).

--g

On Wed, 22 Nov 2006, Jason L Tibbitts III wrote:

>>>>>> "CB" == Christopher Blizzard <blizzard at redhat.com> writes:
>
> CB> If we are able to collect a set of hardware profiles for people,
> CB> just after an install, and tie that to a unique machine
> CB> identifier, we could make that really useful for people. The
> CB> reason being that having access to information about what hardware
> CB> people are really using allows us to know where we need to
> CB> concentrate our efforts.
>
> I and I'm sure a good portion of Fedora users would happily install
> a package that periodically sent various bits of info related to what
> hardware is in the system, what packages are installed, what kernel is
> currently running, etc.  Such information could be immensely useful to
> community packagers as a validation that their packages are actually
> being used somewhere.
>
> There are all sorts of useful bits of information we could collect,
> most of which require that some client be installed.  I suggest that
> this isn't a problem as long as:
>
> There's only one thing to install, not a collection of random
> info-gathering clients.
>
> The client runs from cron and doesn't consume any memory when it's not
> running.
>
> It is not installed by default.  The installer can ask, sure.  "Please
> help us improve Fedora!  Do you want to install the blahblah client?".
> "Yes" should probably not be the default choice.  (It could be
> installed by default but not enabled by default, but even that is
> probably pushing it.  It's about the appearance of impropriety.)
>
> The list of information gathered is presented to the user somehow.  An
> option should be there to provide someone (root?) with a report of
> everything sent in when it's sent in if someone really wants to know.
> Updates to the package which provide new information-gathering plugins
> should not cause those new plugins to be enabled without user
> intervention.
>
> That's pretty much all the evil-minimization you can reasonably do.
> The question is whether the response rate will be high enough and
> whether the responses you get give you a statistically valid sample.
>
> - J<
>
> _______________________________________________
> fedora-advisory-board mailing list
> fedora-advisory-board at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-advisory-board
>

-- 
-------------------------------------------------------------
Greg DeKoenigsberg || Fedora Project || fedoraproject.org
Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors
-------------------------------------------------------------