On 06/17/09 13:19, Evan Layton wrote: > Karen Tung wrote: >> 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. >>> >>> >>> thanks, >>> -ethan >>> >> IMO, I think #1 is the better approach. It allows the separation of >> functionality, and the single log file. The location of the log file >> can also be documented, so, users would already know about it, >> and not have to go through the SMF logs to find the path. Additionally, >> since the log file will exist in a standard location, users would know >> about it after referencing it after a few times anyway. >> Having a separate log file also has the advantage that if we >> ever want to implement any of the features as non-SMF service, the >> application >> can still write to that single well-known log file. > > I agree, #1 seems like the best way to go here. I also like the idea of > having this log in a well-known location that can be used by both SMF > services and non-smf part of the install. > > -evan
I also think #1 is the better of the two alternatives and, as others do, like the flexibility provided by the known location. Sue
