[bind10-dev] location of specfiles in source tree

[Stephen Morris]

On 17/02/12 18:36, Michal 'vorner' Vaner wrote:
> Hello
>
> On Thu, Feb 16, 2012 at 05:08:50PM +0100, Jelte Jansen wrote:
>> :
>> In the installed directory; this would be easy, they are placed
>> together in one directory. In the source tree, however, this would not
>> (since they are all, quite logically, placed with their module).

Git is able to hold symbolic links, so create a directory in the source 
tree that holds links to the various .spec files.  If used purely for 
locating the files when testing code in the source tree, it would not 
require any changes to build scripts or location of the .spec files.

> This might or might not be helpful. Anyway, before going into this, I'd like to
> know the whole plan, because it might turn out it is not necessary at all, and
> having the spec files locally is kind of neat. What I see as a bigger problem is
> how to handle validation of the configuration.
>
> So, the approaches I see are:
>   • Handle everything as configuration plugins. This would have few small
>     advantages, besides the ability to configure anything offline:
>     ◦ It could be an easy way to solve our problem when we have an error in one
>       of the modules, that the modules that happened to be notified sooner keep the
>       new version, but the modules later in the notification keep the old one. This
>       way, we could run the checks first, write it down to file and notify
>       everybody.
>     ◦ We could get rid of all the stupid validation checks through our code. The
>       clutter the configuration code.
>     ◦ No need to distinguish between remote and local configuration.
>     ◦ No more problems of having multiple instances that answer to the same
>       notification (possibly differently).
>     Disadvantage is, we would need to move all the code that checks configuration
>     from C++ to python and from python programs to external modules.

I'm not clear about why we need to move code that checks configuration 
from C++ to Python.  If the configuration checking code is written in 
C++, repackage that into a shared library that can be linked into the 
module itself or into programs such as bindctl (via a suitable Python 
wrapper).


>   • Don't do any offline validation. Just warn about it, or something. This is
>     obviously not very user friendly.

Agreed.

>   • Add a --check parameter to each module. In that mode, it would just start,
>     connect to the config manager, answer if the config is OK and terminate. But
>     that might need some work to modify the startups, etc.

... but this would still require that BIND 10 is running, which is not 
really "offline".


> Having the opportunity, I'd like to propose designing not only the
> configuration, but also:
>   • How will multiple instances of components interact with configuration,
>     statistics and commands.

I think we need to develop the idea of "component" and "process", by 
which I mean that a component is part of the system that has defined 
functionality and which is implemented by one or more identical processes.

So when it comes to statistics, each process should collect information, 
but the statistics analysis code should be able to produce a report of 
the data broken down by either process or component.

>   • Have the ability to accept the config, but issue a warning about the values,
>     or to return multiple errors (well, that is possibly by joining them all with
>     \n).

Agreed.


>   • Have an ability of commands to send some "Attention/Warning/Question"
>     messages to user. If the user is connected to cmdctl, it would show them
>     right away (so if I reconfigure something, it gets through the validation,
>     but then something breaks as a result, I probably will be lucky enough that
>     it will break soon enough before I disconnect, and see it without the need to
>     look into logs). If not, well, that would be the question. Log them? Store
>     them and show them when the user connects? Email them to the user?

Communication from a background process to a logged-in user is a 
separate question from configuration and is not one I think we need to 
concern ourselves about.  There are packages available that will handle 
alerting the user and are more sophisticated than anything we could 
write as part of BIND 10 (e.g. Nagios, a widely-used system-management 
tool, can be configured to scan logs and send alerts on particular 
messages).

Stephen