[sos-devel] sosreport manifest?

[Bryn M. Reeves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/12/2012 02:45 PM, Mike Clark wrote:
> But, a manifest that just lists the file contents doesn't' provide
> any benefit over what we already have.  What I'm interested in is
> what

If it just listed file content there wouldn't be much point in having
a discussion of what it should contain.

> "upcoming changes" you envision.  That should be driving the need
> of a manifest.  I.e., we don't need a manifest now, we only need it
> when we have those changes and, thus, the manifest becomes part of
> those changes, not a separate thing.

I disagree. We already have a problem with how consumers access the
information in an sosreport tarball. This is about not making that
problem worse over time as we make changes and add features rather
than supporting any specific additions.

One specific change that will drive changes here is the need to have
multiple instances of the same configuration file as I mentioned earlier.

> Here, too, what are these use-cases?  I think that we need a fairly
> high bar to do any processing beyond "read this data from this
> path."  I.e., nearly all analysis should happen server side.
> Commonality can happen on the server-side analysis libraries.

What server are you talking about? Note that any changes or additions
sos makes here do not preclude interested parties from creating their
own abstractions however looking at what is out there today that
doesn't really seem to be happening (I spent about 20 minutes last
week and found three or four different pieces of code to determine the
architecture of an sosreport. That is insane).

Think about use-cases such as answering questions like:

 "How many nodes are in this cluster?"
 "Is this system part of a RHEV environment?"
 "Is this system virtualized?"
 "What are the WWIDs of all visible storage devices?"
 "What is the total set of PCI IDs visible to this host?"
 "What is the topology of the PCI busses in this system?"
 "What is the value of property $foo in configuration file $bar?"
 "How many instances of httpd are configured to run on this host?"
 "Enumerate the configuration file paths of the configured httpd
  instances"

Etc.

> Also, I'm I also am interested in how opaque you are thinking the
> report should be.  The implication here is that it is completely
> opaque and should only be accessed through an API.  Is that the
> thought?  (If so, I have many reservations.)

Not at all; downstream users are free to use the data any way that
they want. BUT as with any structured data format that does not have a
rigid specification consumers that chose to invent their own access
methods may be directly exposed to changes that they would have been
insulated from by using an API.

This is something intended to benefit and simplify the lives of
consumers of the data.

Regards,
Bryn.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9eDz8ACgkQ6YSQoMYUY94OSQCg1y0BxCfnGfWU2cX+IkoSS8HJ
jHcAn1ENDNVdewjJI/kcXaDu1Rysws4C
=hTwt
-----END PGP SIGNATURE-----