rpc.kstatd: Remote Kstat Access Service [PSARC/2008/502 FastTrack timeout 08/13/2008]

[James Carlson]

Erik O'Shaughnessy writes:
> > As long as there's no identification of the specific data needed,
> > there's no good way to enumerate what needs to be nailed down.  Either
> > the documentation for this new feature needs to point out the risks
> > inherent in relying on the data without specific documentation of the
> > stability of the kstats in use, or a different solution is needed.
> 
> I have no problem with documenting that "Here there be dragons" in the  
> man page for rpc.kstatd ( or where ever else it is deemed appropriate ).

I think you're headed down a blind alley, but as long as you can point
out these factors in the documentation, I'm happy:

  - Most kstats are intentionally undocumented implementation
    artifacts.  This means that they may change at any time, and
    without warning, including in bug fix patches.  (A few kstats
    *are* explicitly documented as having some stability.)

  - The protocol provides no means for versioning between the
    implementation that defines a given kstat and the client that may
    be consuming it.  Since different hosts on a network may be at
    different patch levels (or entirely different releases), and since
    there's no way to attribute a version to a kstat definition,
    there's no _reliable_ way to detect or handle incompatibilities.

  - Applications built on implementation artifacts without sufficient
    means in place to handle changes may break at any time, and such
    breakage would ordinarily not be considered a bug in the system
    supplying the kstats.

  - Some of the libkstat interfaces may now return new errors related
    to network failures (such as having the target system be
    unreachable) that don't exist with local kstats.  Some networking
    failures (such as a reboot between snapshots) may be undetectable
    by the underlying transport, which means that applications may see
    statistics that move backwards over time.

  - Obviously, all of this is highly Sun-specific and not portable in
    any sense.

Whether someone can convince the kstat suppliers to hold enough stable
to make this useful for some application is perhaps an issue for some
other project.

For what it's worth, the lack of "simplicity" in SNMP is due at least
in part to the sorts of issues above.  Putting raw kstats on the wire
is a nifty hack, but I don't think it's a sufficient way to build
reliable administrative applications.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677