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 :) ----- Original Message ----- > 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