Karen Tung wrote: > jeanm wrote: >> Karen Tung wrote: >>> Jan Damborsky wrote: >>>> Glenn Lagasse wrote: >>>>> * Karen Tung (Karen.Tung at Sun.COM) wrote: >>>>>> Hi Glenn, >>>>>> >>>>>> These messages are generated from the exec_cmd_outputs_to_log() >>>>>> function >>>>>> in usr/src/lib/install_utils/install_utils.py. Looking from the >>>>>> change history >>>>>> of this file, the following putback is the one that made the change: >>>>>> >>>>>> changeset: 635:74823d433dc4 >>>>>> user: Jan Damborsky <jan.damborsky at sun.com> >>>>>> date: Mon Nov 09 14:19:53 2009 +0100 >>>>>> summary: 6651 autoinstall needs more useful error messages from >>>>>> Orchestrator >>>>>> module >>>>>> >>>>>> All commands invoked by DC uses the exec_cmd_outputs_to_log() >>>>>> function. >>>>> >>>>> Ah-ha. That helps. So looks like changeset 635 was a tad aggressive >>>>> :-) >>>>> >>>>> I'll follow up with Jan. Thanks Karen! >>>> >>>> Hi Karen, Glenn, >>>> >>>> confirming that changeset 635 is the culprit :-) >>>> >>>> No doubt that 'pkg' prefix in DC log is confusing and has to be >>>> removed. >>>> WRT having the command logged, I would like to check if it is in >>>> general >>>> something which could be acceptable in DC log. >>>> I am asking, since it is useful source of information in installer >>>> case >>>> and if something fails, there is an easy way to exactly reproduce >>>> the set >>>> of steps which led to the failure. >>>> >>>> Thinking about solution, we could >>>> >>>> [1] Repair the prefix >>>> [2] Avoid logging the command in DC case >>>> [3] Remove logging the command completely from >>>> exec_cmd_outputs_to_log() >>>> >>>> Please let me know what you think. >>>> >>>> Thank you, >>>> Jan >>>> >>> Hi Jan, >>> >>> Having the exact command logged is certainly useful for debugging. >>> Many times in the past, I also modifying the function so the command >>> that's being executed gets printed, when I have debug something. >>> >>> The only concern I have is that some of the command that get executed >>> have very long argument lists. I don't know whether that will be >>> confusing to people. >>> To give an example of a long command that gets executed: >>> >>> ------------- >>> /usr/share/distro_const/finalizer_checkpoint.py >>> /tmp/ManifestServ.8418 /rpool/dc-bld/ti/build_data/pkg_image >>> /rpool/dc-bld/ti/build_data/tmp >>> /rpool/dc-bld/ti/build_data/boot_archive /rpool/dc-bld/ti/media >>> /code/ti-dev/text_jean.xml /rpool/dc-bld/ti/.step_post-mod >>> rpool/dc-bld/ti/build_data at .step_post-mod ==== post-mod: Post boot >>> archive image area modification >>> ------------- >> >> Does this mean that the above would also get printed to the screen? >> If so, I think it's too long and confusing. >> How about if this was only printed to the detailed log and something >> simpler to the simple log and the screen? >> >> Jean > Depending on how we do it, we can certainly only print the command to > the detail log, and not to > the screen or the simple log at all. Even just printing them to the > detail log, I am not sure whether all > the extra output will confuse people and let other useful data be missed.
Those messages are only captured in detail log. I tend to believe that in general user interacts with DC via console which is supposed to provide information about progress and the result of the build - and if failure occurs provide some guidance. log file is to be inspected only in case of failure or for debugging purposes. In these cases I think it would be useful to have rather more than less information available. Jan
