[Gluster-devel] regarding gluster msg ids
pcuzner at redhat.com
Fri Apr 11 02:50:02 UTC 2014
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.somari at gmail.com>
> To: "Pranith Kumar Karampuri" <pkarampu at redhat.com>
> Cc: "Ravishankar Narayanankutty" <ranaraya at redhat.com>, "Gluster Devel"
> <gluster-devel at nongnu.org>, "Shyamsundar Ranganathan"
> <shyamsundarr at 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
> 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 :) ).
> On Sat, Apr 5, 2014 at 8:36 PM, Shyamsundar Ranganathan
> <sam.somari at gmail.com> wrote:
> > On Fri, Apr 4, 2014 at 4:07 AM, Pranith Kumar Karampuri
> > <pkarampu at 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 at nongnu.org
> >> https://lists.nongnu.org/mailman/listinfo/gluster-devel
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel