Alok Aggarwal wrote: > > On Wed, 17 Jun 2009, Ethan Quach wrote: > >> Alok Aggarwal wrote: >>>>> - Also, since this smf service is separate from the the >>>>> auto-install smf service, >>>>> how would the output/error from this service be reported? Will it >>>>> be a separate >>>>> log file from the auto-install service? >>>> >>>> Its a separate log file. >>> >>> One of the things the AI client redesign proposes >>> is to consolidate all the installation related >>> logging into the auto-install service log. A central >>> log location like this helps users in not having to >>> look at multiple places to determine what's going on. >>> >>> It seems we're moving in the opposite direction by >>> creating another log file the user needs to keep >>> track of. >> >> As per our discussion on this at the meeting, I asked Liane >> about adding additional log file pointers to service definitions, >> and there currently isn't a proper way to do this. In a service >> definition, there are tags to define doc links and manpage >> references that do get displayed with svcs -x, but these are >> metadata of the service, and not really fit for specifying the >> log file. If we really want to be able to this, we could file an >> rfe. >> >> >> With the goal of having a single install log file in mind, we >> have a couple of options >> >> 1. define the single install log file to be a separate file, and >> have each of the SMF service log files note where the install >> log is in their content. This imposes an additional step for the >> user to -- look in smf log to get install log path, then go to >> actual install log -- but it keeps the functional separation of >> the services and provides for the proper granularity of restart >> and dependencies of the functionality we've defined. Also >> when the rfe is fulfilled, we'll be able to note the separate log >> file in the svcs -x output. >> >> 2. combine what we've functionally proposed as the manifest >> discovery service back into the auto-installer service. We >> obviously lose benefits described above for #1. >> >> >> Please provides opinions/thoughts. I would like closure on >> this by today if possible. > > #1 is better than the alternative. Especially given that the > deficiency in SMF doesn't allow us to satisfy the requirement of > following the svcs -x output for diagnostic purposes unless we go with > a single service. > I agree #1 is the best solution given the current limitations in functionality.
> So, I guess it boils down to the question of whether we want > modularity by sacrificing serviceability a small amount. I think we want modularity. I think the benefits of separating out the manifest service from the AI service outweigh the users having to be pointed to the full log for more data. sarah **** > > Alok > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
