[Gluster-devel] regarding gluster msg ids

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
> 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.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
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140410/b7f1d9db/attachment-0001.html>