[bind10-dev] Task 1005 - Check Logger Names in cfgmgr

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/27/2011 05:59 PM, Michal 'vorner' Vaner wrote:
> Hello
> 
> On Mon, Jun 27, 2011 at 03:55:45PM +0100, Stephen Morris wrote:
>> A solution that occurs to be that should be simple to implement
>> (although not very elegant) is to maintain a list of valid logger names,
>> and check against it both when creating a logger and when configuring one.
>>
>> The list doesn't have to be a text file - it could be some hard-coded
>> list of names in the liblog library with an interface to access it from
>> both C++ and Python.  Of course, the list would need to be updated every
>> time a new logger was added to the code, but that is unlikely to be a
>> common occurrence.
> 
> That sounds error prone to me. But I see another problem. We currently can do
> these things from the configuration plugin:
> • Return a hard-error. This suggests it should be a warning.
> • Log a message, which is not presented right away to the administrator sitting
>   at cmdctl.
> 
> So, even if we go with the non-system solution (which might be the best thing
> for now), we need a way to push the warning all the way trough multiple
> interfaces to the config manager. That sounds nontrivial to me.
> 

nontrivial, but not extremely hard (we could either extend the current set of
possible responses, which are 'ok [data]' and 'error <message>', with a third
option 'ok, but...', or add an optional [warn] to the success response.

However, I'd say the harder part is knowing what are valid logger names.

I don't like the idea of a hardcoded list either; I think we want to support
additional modules that we didn't build to have logging too.

> And if we want to have some way to guess the list at runtime, we would better
> solve the problem with offline configuration first.
> 

Yep. Same problem. Part of the solution for that will be having our .spec files
not scattered all over the place, but put them all in a specific location
(similar to the way all 'virtual' modules specfiles are now below
bin/cfgmgr/plugins). Then we can know what modules have loggers (since they all
have a specfile, unless someone handcoded their own logging into it). If we know
all module names we can at least make sure the first-level logger is correct.

As for the second level, I don't think we can predict, nor discover those
reliably. So if we want to be able to check those as well, we do need a list.
I'm thinking that if we want that the most logical place would be the specfile
(in its own category 'logger_names').

Note that another thing we would need to do is match root logger names with what
is in the specfile (something that I think is also needed for #1003), and get
rid of the capitalized names we have now (btw, we could read the root logger
name *from* the specfile, but we probably want to initialize the logger way
before that).

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4I4t8ACgkQ4nZCKsdOncUBvQCeL4KDQUu6s69kRTNGbyj+GVer
gPAAoMdm+03syiJOUF3PU5AEYtTqe9u9
=Rt35
-----END PGP SIGNATURE-----