On Sat 28 Oct 2006 at 10:10AM, Mike Gerdts wrote:
> On 10/28/06, Menno Lageman <[EMAIL PROTECTED]> wrote:
> >How about something like the DHCP eventhook mechanism (see
> >dhcpagent(1M))? This would allow people to get notifications of zone
> >state changes in a well defined *and* simple way without the need
> >scraping logs for unstable messages.
> >
> >zoneadmd just needs to invoke the Zone eventhook with the appropriate
> >event and some auxilary data for the event (such as zone name etc). The
> >sysadmin-supplied eventhook script would then do whatever is deemed
> >appropriate for the site (page someone, send mail, forward to management
> >console etc.).
> Assuming that the code that Dan wrote calls the eventhook rather than
> sending syslog messages, I like this approach more.  Compared to
> sending syslog messages, it has the advantages that Menno mentions.
> Additionally, it would provide a mechanism for customers that need to
> perform other things when a zone state changes.  For instance, when a
> zone boots there may be a need to do something special to the network
> (alter routes, mtu, etc.).  This would be a much simpler hook for that
> than hacking the zone SMF method script.

We're certainly aware of these RFEs.  In this case, I was attempting to
respond rapidly to a pressing customer need (actually it turns out that
this customer has been asking for this for a long time, and I feel bad)--
but if it's seen to be too much of a kludge, I'll accept that.

Hooks are not as simple as they might appear.  We have a coming
collision with our zones SMF conversion (phase II), in which we expect
that each zone will be represented as a service instance.  We also know
that the SMF team is planning a "state transitions" hook API which
should allow this sort of hook-driven administration for *all* SMF
services.  So I've been reluctant to put this in until we're sure that
it won't be replaced during that collision.

Additionally, there's a difference in my mind between a hook which
happens after (but asynchronously with respect to) an event, and a hook
which must run to completion before allowing the flow of control
to continue.  There's also the question of whether hooks should be
able to be configured globally (for all zones of a particular brand)
or at a per-zone scope.  Or both.

So it's not that I disagree.  The question is whether this RFE is
useful to folks when considered side-by-side with a hooks project.
Would always having syslog messages for state transitions be nice?  That
question is what we need to resolve here.

> # ./notify
> foo 6 shutting_down running
> foo 6 shutting_down shutting_down
> foo 6 shutting_down shutting_down
> foo 6 shutting_down shutting_down
> foo 6 uninitialized shutting_down
> foo 7 ready uninitialized
> foo 7 ready ready
> foo 7 running ready
> I'm not sure why the newstate and oldstate would be the same.

Nice work (although I would discourage people from writing or using
programs to this undocumented, unstable API--- that's why we make it
hard to link against libzonecfg).  The reason for the non-obvious
transitions is that you're seeing the various internal state changes,
several of which map to the single user state "shutting_down." See
kernel_state_to_user_state() in libzonecfg.c.  There is a bug open
(6377283) to correct this, although it's mostly harmless.


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

Reply via email to