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. -dp -- Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp _______________________________________________ zones-discuss mailing list firstname.lastname@example.org