Hi Niall,
Niall Power wrote: > Hi Jan, > > On Tue, 2008-03-04 at 19:54 +0100, jan damborsky wrote: >> Hi Niall, >> >> thank you for your comments - >> please see my response in line. >> >> Jan >> >> >> Niall Power wrote: >>> Hi Jan, >>> >>> Overall the design looks solid to me. One major point I'm not convinced >>> about is the >>> idea of having separate logging and debugging services. What is the >>> advantage of >>> separating them out? On the list of disadvantages I see the following: >>> - It doesn't seem unified to output to 2 separate destinations. >> The reason why it was decided to have two separate "capture streams" is >> that each of the service hits different target group of consumers - >> users and developers. >> >> Since log file can be displayed directly from installer and thus >> is visible to regular user, it was considered that it would contain >> only messages providing status and progress of the installation >> process and should have relatively high signal to noise ratio >> from user's point of view. Also at some point it was being discussed >> that since these messages can be displayed from within installer, >> they could be localized. > > Shouldn't it be the job of the GUI to display progress and status > messages to the user during installation rather than expecting them > to search through a text file? Are we just importing excess baggage > from the pfinstall days or is there a real need to provide an > installation log for end users? My expericene in this area is limited > so I genuinely don't know. You are right that if user uses GUI for installing Solaris, GUI takes care of providing user with status and progress of installation process and it is likely that if everything goes fine, user will not take a look at log file at all. In this case, log file would rather serve as recorded history how the Solaris instance was originally put on target. On the other hand, if user selects non-interactive way of installation (for example using AI), the log file would be the only way how to inspect what happened during installation process. That said, I agree with you that this is the way how pfinstall in general took care of logging and I am open to suggestions how we might do it better in order to provide user as well as developers/testers with reasonable set of information in suitable way. > >> On the other hand, debugging service was designed to provide installer >> with possibility to capture all information necessary for engineer >> to track down cause of potential issue - it thus might contain a lot >> of information which might be useless or even misleading to the user. >> And these kind of messages are not subject of localization process. >> >>> - The debug log doesn't get preserved after installation. A debug log may >>> contain key >>> pieces of information that the other log file doesn't. For hard to >>> reproduce bugs etc. >>> the debug log may be all we have to go on if the problem can't be >>> reproduced internally. >> Agreed - if we decide we will continue to use two separate files, they both >> will have to be preserved - the orchestrator would take care of this. >> >>> - Data may get logged inappropriately because it is up each individual >>> working on different >>> parts of the code to decide whether a particular event or situation is a >>> logging or a debugging >>> situation. Things could become inconsistent quite easily. >> This is good point - actually this reason is why I am not quite >> convinced that >> using two separate files is perfect solution. For now there are no strict >> criteria, which might be followed when this kind of decision has to be made. >> >> But I think we will need to make this decision, even if we use one common >> logging service (for example by setting message verbosity level), since >> I think that debug messages should remain hidden to the user by default. > > Perhaps we could make a rule that anything that goes to the logging > service should also be communicated to the user via. the GUI. That's > just the first idea that came out of my head. Although I do believe that > we shouldn't expect the user to be monitoring a text file to monitor > the installation process. I completely agree - during GUI installation, GUI is the interface between installer and user - log file would only record the information GUI provided to user during installation process - for example if he is interested to take a look later, since he didn't pay attention during process itself. > But I still think that a unified file provides a better overall picture > of what was going on in the installer. Also, in a typical installation > where we don't expect to have many problems, debugging messages should > be very few, only being generated if problems occur if a high debugging > level is explicitly set via an environment variable or an API call from > a special debug build binary. Generally we won't expect to see errors > or warning messages, hopefully :) Yes - this would be the ideal case :-) At this point I tend to the approach, that one common file might be sufficient for these purposes, but I think that it would help to create better picture if we might obtain opinions also from other potential consumers (transfer module, AI, ...), since they might be using this logging service in slightly different way. Thank you, Jan > > Thanks, > Niall. > >> >>> Thanks, >>> Niall. >>> -- >>> This message posted from opensolaris.org >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
