Susan Sohn wrote:
> 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
FWIW, I think #1 is the better option as well. I also feel we should
file an RFE against SMF to allow custom log file locations, so we're not
setting a weird precedent of overriding the "expected" behavior of SMF
log files.
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
