On 07/14/2016 12:08 PM, Petr Cech wrote:
On 07/14/2016 11:35 AM, Michal Židek wrote:
On 07/14/2016 10:12 AM, Pavel Březina wrote:
We recently focus on providing lots of tracing messages in new code that
helps us follow the code, however this makes the debug logs quite big
and we usually focus only on a specific area or task while debugging. A
year ago we discussed what we can do to improve our debugging
capabilities but it never got into action since we hit the long standing
requirement to revisit all debug messages and their levels.
1) Originally, we had only numeric debug levels. The problem here was
that those numbers were assigned relatively randomly per developer
decision.
2) My first task when I joined the team was to change the levels from
numeric to a bit mask. This seemed good at first as it allows to select
specific messages that we want to see but it was never polished into a
usable feature for two main reasons -- it required us to revisit all
existing messages and it turned out it actually doesn't make much sense
to disable any lower level since if you want to see tracing message you
always want to see error etc. So in the end the bit mask is used in the
same way as numeric representation (if used at all) it is just harder to
read.
My needs when debugging some issue are very simple -- be able to see as
small log as possible but having all errors and tracing messages. The
problem usually lies in a small area of code and I don't need to see
other parts of code that hinders these messages.
As a developer I would like the change into new format be seamless so it
does not require manual changes into current code. And I would also like
to have smaller number of choices.
What I propose is this: have a numeric debug level and a bit mask
representing an sssd component.
*Debug level*
0 = Fatal failures, important messages. Always enabled. For cases that
prevents SSSD from starting and for very important messages.
1 = Errors, for any error that we can recover from.
2 = Warnings, for unexpected situations were we can actually continue
with the operation. (E.g. when processing bunch of objects in a for
cycle and continue on error).
3 = Data, for user input, configuration.
4 = Trace, for tracing code flow.
5 = Verbose, for things that are very rarely required and would just put
lots of things into logs (e.g. verbose information about sudo rules).
*Component*
An SSSD module as separated from the rest as possible. For example: all,
failover, sudo, id, subdomains, ldb, ... lots of possibilities.
SSSD needs to be started or configured with two options
--debug-leve=number, --component=bitmask (default all). Messages with
level <= numeric and component & mask are printed.
Ideally components can be separated also on makefile level into static
libraries that we will link with. This would help with unit testing
those parts since we wouldn't have to maintain source file list in unit
test definitions but link with a library instead. It would also speed up
compilation. This library could have -DSSS_COMPONENT_NAME=$name and we
wouldn't even have to put it in DEBUG macro.
Separating on makefile level sounds nice. I like the idea of having
SSSD split into several libraries. As you mentioned this would speed
up the compilation. Also as part of this effort we could clean up
the mess in our source file dependencies.
But this effort could take more time, maybe we could use
something else in the meantime. Ideally something that will
be forward compatible with the solution you proposed.
What about having the #define SSS_COMPONENT_NAME at the
beginning of .c files? We could do this before the split
into libraries. When the libraries are made the
the #define SSS_COMPONENT_NAME can be removed, because
it will be defined in the makefile.
+1 I appreciate this proposal
I see the work as following:
1. Make DEBUG macro work with SSS_COMPONENT_NAME bitmask defined (as
well as undefined - current behavior)
2. Make list of components that we want to be defined.
3. Work on splitting the code into libraries
3a) #defining the component names in .c files (after this we can
already use the new debug levels functionality), but we
should not yet document the new behavior.
3b) When all are agreed on how the code is split into the
components, we can modify the Makefile.am (to actually make
the libraries), if not, we can update list from point 2.
or rethink the 3a point until developers come to an agreement.
3c) We can remove the #defines from .c files
4. Document the new behavior so that other people can use it.
+1 This sounds good to me.
I would like to vote for do it one by one component and not like one big
patch with all components switching to new debug schema.
The intent is to do it for new or refactored code, not changing the
existing if possible.
Thoughts?
+1 for opening up this discussion.
Michal
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
