Paul, Just adding to the context (or stating the obvious),
The gluster messages would contain the following format, [date&time] [SEV] [MSGID] [code location] [xlator/component] <message> So it should cater to picking up on sev, xlator/component, and based on the message ID, don't panic ;) Shyam On Thu, Apr 10, 2014 at 10:50 PM, Paul Cuzner <pcuz...@redhat.com> wrote: > > This is really interesting - I've worked on systems (z series) that used > msgid's across a mass of products, based on a <product > prefix><seq#><severity> format > > That worked really well, since operations picked up on the prefix and > immediately new what subsystem the message related to....and whether to > panic or not :) The messages could also be sent to the same logging > subsystem, and then automation could just pick the one file and get a view > across all products. > > Ahhh - good times :) > > > > > > ________________________________ > > From: "Shyamsundar Ranganathan" <sam.som...@gmail.com> > To: "Pranith Kumar Karampuri" <pkara...@redhat.com> > Cc: "Ravishankar Narayanankutty" <ranar...@redhat.com>, "Gluster Devel" > <gluster-devel@nongnu.org>, "Shyamsundar Ranganathan" > <shyamsund...@gmail.com> > Sent: Friday, 11 April, 2014 1:10:26 PM > Subject: Re: [Gluster-devel] regarding gluster msg ids > > > Updating the thread with some more context from discussions offline > between Pranith, Krutika and myself. > > The issue(s) that led to moving from a numeric ID to a string notation > of the #define was due to > - fragmentation of the message range once allocated segments were full > - Ability to define more developer friendly #define names, making > code better understandable > - Based on the #define adding better meaning to the message itself > > Based on this it was discussed and concluded that we will standardize > on numbers as an externally visible entity rather than have developer > defined strings as the ID, > - so that it looks and feels consistent across components > - as we do not need to add more meaning to the message ID but > rather to the message when required and, > - also we need to leverage the ID as potential candidate for > journald/systemd subsystem when moving to that (potentially) in the > future. > > Developers still have the flexibility to use any define names for > messages in their component, so that code reading is better. > > Message range fragmentation would continue, but that is a smaller > problem which can be avoided taking larger/more segments as the > component may need/choose. > > A compile time step would be added to prevent multiple definitions of > message defines (as suggested by Jeff) by adding a precompile script > to each message file to generate a conversion from #define to const > char * variants of the message.Then do a compile of this generated > header, which would fail in case there are duplicate const char * > defines. (rereading this line does seem like a lot of information in a > single line, so will follow this with a code submission to elaborate > the concept better :) ). > > Shyam > > On Sat, Apr 5, 2014 at 8:36 PM, Shyamsundar Ranganathan > <sam.som...@gmail.com> wrote: >> On Fri, Apr 4, 2014 at 4:07 AM, Pranith Kumar Karampuri >> <pkara...@redhat.com> wrote: >>> >>> hi Shyam, >>> Instead of printing numbers as msg-ids, could we print the >>> stringification of macro itself as the msg-id? Reasons why I feel this is >>> better: >>> - No need to worry about msg-id range segment overlaps as we are not >>> dealing with numbers anymore. >> >> What is the current problem in segment overlaps? The intention is to >> get separate segments per component, so that way each segment is >> unique. >> >> Why wont these message names rather than numbers not clash? IOW, if 2 >> components choose the same macro names then an entire name space would >> clash. >> >> Look at these message ID segments like the mem types assignments. >> >>> - macro re-use in same file will cause compilation error. Different >>> msg-id.h files will have different prefixes for msg-ids so there should not >>> be any collisions across components. >> >> Macro reuse (as stated in the followup by you) is a separate problem, >> which needs to be dealt with using gcc preprocessing of the headers >> during compile time, to eliminate the possibility of duplicate macro >> names within a single header. >> >> const char * definitions will not help catch preprocessing time format >> and types error with the __attribute__ ((__format__ (__printf__, 9, >> 10)) check. >> >>> - We can choose to give easy-to-remember msg-ids like AFR-SPLIT-BRAIN >>> if we want to. No need to lookup what msg-id means etc. >> >> Admins who are looking at logs are not looking for clues from message >> ID per se, they are looking at an ID to look up and understand what it >> means, hence any unique string/number can serve as the ID. Please note >> this is not for developers to look at and debug from the logs. >> >>> >> >> Here is a broader overview of the message ID versus the string proposal >> from me. >> - Other similar systems use and ID, which in systemd parlance can be a >> GUID or some such distinct identifier per message (say message >> catalogs for systems from Cisco etc.) >> - A string of the form suggested is still a unique message ID, but >> when we integrate to systems like systemd, such IDs may not work, we >> need definite numbers >> - When it comes to documentation, which the admins would refer to, an >> ID is easier than a string in the message to simply put a list of >> messages up for the administrator to look at and search >> >> In short, what is the segment clash issue, and what is the code >> maintenance issue that is being discussed with the current mechanism, >> moving to a string does not seem to satisfy the requirements for this >> framework at the moment from my perspective. So it is better to >> understand what the segment allocation issue is first. >> >>> I sent a first-cut patch at: http://review.gluster.org/7398 >>> >>> TODO: Remove segment related macros if you guys also like the change. >>> >>> This is one of the messages with and without patch above: >>> [2014-04-04 07:08:53.113969] I [MSGID: glusterfsd_msg_30] >>> [glusterfsd.c:1914:main] 0-glusterd: Started running glusterd version 3git >>> (args: glusterd --debug) >>> [2014-04-04 07:10:49.687053] I [MSGID: 100030] [glusterfsd.c:1914:main] >>> 0-glusterd: Started running glusterd version 3git (args: glusterd --debug) >>> >>> >>> Pranith >>> >>> _______________________________________________ >>> Gluster-devel mailing list >>> Gluster-devel@nongnu.org >>> https://lists.nongnu.org/mailman/listinfo/gluster-devel > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/gluster-devel > > _______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
