Jean McCormack wrote: > Dave Miner wrote: >> Jean McCormack wrote: >>> >>> We have an interesting problem on the SMF work with respect to >>> enabling the SMF service when commands are run. >>> >>> The general premise we've been working under is that if no install >>> services are "on" then the SMF service should be in maintenance. >> >> "when the SMF service is enabled", of course. >> >>> Also, all command should cause an attempt to enable the SMF service >>> when they are executed. >>> >>> Our problem: >>> If the SMF service is enabled when running a command like >>> create_service or enable and there are no install services "on" we >>> go into maintenance mode and can't enable the service or create it. >>> Chicken and the egg problem. >>> - We want the service to go into maintenance and the command to >>> error out if a dependency is unfulfilled. But not if if there are no >>> "on" install services. >> >> I don't understand the "but not..." here. If it's enabled with no >> install services enabled, then the general premise stated earlier >> would seem to dictate it goes to maintenance. >> >>> - We don't want this behavior if we are creating/enabling the first >>> install service. >>> >> >> I don't see the problem; why can't you create the install service, >> then enable the SMF service? Sorry. I missed this on my last reply. Wouldn't we want to attempt to enable the SMF service immediately? That way if we have any dependency issues that send us into maintenance we would know and not continue trying to create the service.
If this statement is false, then we could do what you say and I believe we have no issues. Jean >> >>> >>> We've come up with 2 solutions to this and would like feedback on >>> them today. >>> >>> Solution 1: Put the SMF service into degrade status not maintenance >>> if there are no install services in "on". This would not be >>> considered an error to exit a command from and the service would be >>> enabled if the command succeeds. >>> >> >> Degraded is really not implemented in any useful way in the SMF >> machinery at this point. I would discourage using it. >> >>> Solution 2: Currently the modification of the status information is >>> at the end of the create_service/enable functions. We could move >>> this to the beginning of the functions and create a 3rd state for >>> status (enabling ???) to differentiate from a full enable. Obviously >>> all error conditions that exit would need to clean up by changing >>> the status back to off or deleting the property group. >>> >> >> This doesn't seem necessary. I would think that there's the state of >> each install service (enabled or disabled) and, separately, there's >> the state of the SMF service. The latter governs whether any install >> services can be used, while the former merely provides a specific >> sub-state for each individual install service. If you create or >> enable an install service, then either enable or clear (should you >> find the install SMF service in maintenance) the SMF service, won't >> you get the desired behavior? >> >> Dave > I'll try to communicate this better with an example. > > 1)install/server:default is in maintenance. We have no install > services enabled. > 2)The user types installadm create-service. This is supposed to > enable/clear install/server:default. > 3)When we enter the installadm code we immediately try to enable/clear > the install/server service. > 4)We have no install services enabled yet. In fact we have no services. > 5)install/server:default goes into maintenance. > 6) Code exits and prints error message. > > Jean > > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
