Jean McCormack wrote: > 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. >
Yes, Ethan expressed my thinking well enough. Creating install services should succeed irrespective of the ability of the SMF service to run. Dave > 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 > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
