On Fri 27 Oct 2006 at 06:21PM, Dan Price wrote:
> > 
> > Encouraging programmatic use of syslog seems a step in the wrong direction
> > to me.  Surely we can provide a better mechanism to notify them of state
> > changes?
> Such as?

I guess my larger point is that I haven't seen us take steps in the
"right" direction.  Maybe we have and I'm just not aware of them.

To expand a little, the "such as?" could be SMF, which already has the
ability to monitor property values.  However, we're a ways off from having
each zone appear as a service (and even then, you'd have to know that a
particular zone exists in order to be monitoring some particular property
in the repository which represents its state).

I think that some minimal syslogging is warranted (I've tried to keep it
simple here) because we do know that customers have a degree of comfort
with syslog, and because it fits readily into various existing 3rd party
monitoring packages.

As for GPEC, that's what our existing C api is based upon.  Take a look at
zonecfg_notify_*() in libzonecfg.  It's a real horror show but it does
solve the "get the state and then subscribe to future changes and don't
miss anything in between" problem.

We could potentially build this up into some new command like 'zoneadm
monitor' but I don't necessarily see that as being in conflict with doing
something in the short term with syslog-- and 'zoneadm monitor' can't be
consumed by upper level monitoring agents without a lot of work by lots of
other vendors-- I don't see an unconsolidated but versioned and structured
messaging strategy as gaining much traction.  If we want to do versioning
and structured messages *and* tackle the networking and security parts and
make a consolidated stream of messages, then I think that could be


Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
zones-discuss mailing list

Reply via email to