http://defect.opensolaris.org/bz/show_bug.cgi?id=10805
--- Comment #4 from amaguire <alan.maguire at sun.com> 2009-08-20 17:18:35 UTC --- (In reply to comment #3) > > > But I think we need to let the user know that a problem was encountered while > stopping the enm; putting it in maintenance state seems to be a reasonable way > of doing that. Would it make sense to block the events if it's in > maintenance, > rather than just not putting it in maintenance? That seems reasonable, but the problem is the order in which we carry out operations such as commit and destroy is: 1) update the configuration in netcfgd 2) update the state in nwamd This order is needed for commit-type events since nwamd re-reads the configuration for most operations (e.g. commit triggering a refresh). If we accept that this ordering is necessary, we are left in the awkward situation that the object is effectively already gone by the time we run the stop script, so there's nothing to put into maintenance. It may make sense to reverse this order for destroy events, but I'm worried that'll make life quite complicated. I'd also be worried that it would be possible to make undestroyable objects if the script or service didn't exist. -- Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
