Hi Ethan,

thank you for your comments.
Please see my response in line.

Jan


Ethan Quach wrote:
> Hi Jan,
>
> First question I have is, by "installer components", do you mean
> modules that only run in the microroot?  or would modules like
> libbe, which run on an installed system, make use of this logging
> service as well?

I have been initially thinking only about the microroot scenarios,
when orchestrator is involved in install process.
I think libbe is special case, since it will be utilized in both
environments (on installed system for BE manipulation as well as
during fresh install for BE creation).
To be honest, I am not very familiar with the approach how Snap Upgrade
will take care of logging - do you think it might be possible that
libbe could still utilize logging service (in different configuration -
for example log messages would go to the stderr only), even if working
on installed system ?


>
> Why should the default log file be "/tmp/install_log"?

The default name and location was originally inspired by
pfinstall - please let me know if you think we could use
more suitable location - I will change it.

> It seems to me,
> to be a little bit more general in service, the log file should to be
> explicitly set, and setting it via a function call rather than an
> environment variable would be a little bit user friendly.

For now it can be explicitly set to something else by
environment variable. I agree with you that standard C API should
be available as well - I will add it to the design specification.
I think that having possibility to tune logging service by
environment variables would still be useful, since it doesn't
require recompilation - end user then can adjust various
parameters (destination, verbosity, ...) for debugging purposes.
Defining appropriate variable would then overwrite default
behavior set by function call.

>
>
> -ethan
>
>
> jan damborsky wrote:
>> jan damborsky wrote:
>>> Hi all,
>>>   
>> I am sorry - just pressed Sent button TOO early :-)
>>
>> In accordance with current Caiman design document, the
>> common logging service is considered to be utilized by
>> other modules/services for recording/collecting logging
>> and debugging messages.
>>
>> Initial version of logging service was implemented in Dwarf
>> Caiman project and is now used by Target Discovery, Target
>> Instantiation and Orchestrator services.
>>
>> In order to consolidate logging approach across other installer
>> projects/components, the current design needs to be enhanced, so
>> that it provides features and mechanisms required by other
>> potential consumers - Tranfser module, libbe, AI, ...
>>
>> The initial design document is available at
>>
>> http://www.opensolaris.org/os/project/caiman/files/dwarf_log_design-2.pdf
>>
>> The intent here is to collect as much as inputs, suggestions,
>> recommendations as possible in order to accommodate/modify current
>> logging service design, so that it could be utilized/consumed
>> by other installer components.
>>
>> For now at least following enhancements are taking into account
>> * optional adding of timestamp to debugging/logging messages
>> * providing additional C language API for configuration of
>>   logging service parameters (it can be currently configured
>>   by setting environment variables - this will remain)
>>
>>
>> Thank you,
>> Jan
>>
>> _______________________________________________
>> 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


Reply via email to