[Gluster-devel] GlusterFS and the logging framework

[Vijay Bellur]

On 05/07/2014 10:21 AM, Nithya Balachandran wrote:
> We have had some feedback/concerns raised regarding not including the messages in the header file. Some external products do include the message strings in the header files which helps for documentation as well as easier editing.

Is there more detail on the concerns being raised? For documentation 
ease, we can evolve a script to generate a consolidated file of all 
messages in a component. The consolidated file can then be subject to 
i18n etc. in the future.

 From a developer perspective, editing a message would involve an 
additional git grep for the message - it shouldn't be too hard?


>
> Does anyone have any thoughts on this? The advantages are listed above. Disadvantages were listed in earlier emails. If we decide to include messages in the header file, we will need to consolidate all messages that fall into various classes and come up with a single format string - currently there seem to be too many messages that mean the same thing but use different foramts to say it.


I suggest we finalize an approach and go ahead with implementation. My 
obvious preference at this point in time is approach #2 described 
earlier in this thread. In scenarios like this where there are multiple 
options and there is no obvious winner, it is always better to implement 
an approach and listen to feedback from the intended audience of the 
feature. That will let us know whether we are on the right track or not.

Regards,
Vijay

>
>
> Regards,
> Nithya
>
> ----- Original Message -----
> From: "Vijay Bellur" <vbellur at redhat.com>
> To: "Dan Lambright" <dlambrig at redhat.com>, "Nithya Balachandran" <nbalacha at redhat.com>
> Cc: "gluster-users" <gluster-users at gluster.org>, gluster-devel at gluster.org
> Sent: Thursday, 1 May, 2014 1:31:04 PM
> Subject: Re: [Gluster-devel] GlusterFS and the logging framework
>
> On 05/01/2014 04:07 AM, Dan Lambright wrote:
>> Hello,
>>
>> In a previous job, an engineer in our storage group modified our I/O stack logs in a manner similar to your proposal #1 (except he did not tell anyone, and did it for DEBUG messages as well as ERRORS and WARNINGS, over the weekend). Developers came to work Monday and found over a thousand log message strings had been buried in a new header file, and any new logs required a new message id, along with a new string entry in the header file.
>>
>> This did render the code harder to read. The ensuing uproar closely mirrored the arguments (1) and (2) you listed. Logs are like comments. If you move them out of the source, the code is harder to follow. And you probably wan't fewer message IDs than comments.
>>
>> The developer retracted his work. After some debate, his V2 solution resembled your "approach #2". Developers were once again free to use plain text strings directly in logs, but the notion of "classes" (message ID) was kept. We allowed multiple text strings to be used against a single class, and any new classes went in a master header file. The "debug" message ID class was a general purpose bucket and what most coders used day to day.
>>
>> So basically, your email sounded very familiar to me and I think your proposal #2 is on the right track.
>>
>
> +1. Proposal #2 seems to be better IMO.
>
> Thanks,
> Vijay
>
>
>