Sounds like this correlates with Dave's response. If we try to enable/clear after the service is created then we're OK. The service is created and we may or may not be in maintenance at the end of that. An error message will print if we are in maintenance so the user knows something is wrong.
Jean Ethan Quach wrote: > > > Jean McCormack wrote: >> 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. > > IMO a request to create-service needs to create the service regardless. > If the dependency chain isn't fulfilled, that's a subsequent action that > can be acknowledged and rectified outside of the install service > creation. > > > -ethan > >> >> 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 >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
