[bind10-dev] location of specfiles in source tree

[Michal 'vorner' Vaner]

Hello

On Thu, Feb 16, 2012 at 05:08:50PM +0100, Jelte Jansen wrote:
> I just got handed an old ticket (http://bind10.isc.org/ticket/243), in
> which I suggested to group all .spec files in the source tree.
> 
> The problem is this; if we ever want to do offline configuration
> (offline here meaning both non-running modules and configuration
> through bindctl if bind10 is not running at all), we'll need to be
> able to know what modules exist and what configuration they (can)
> have. So an obvious way to do that would be to read all known
> specification files.
> 
> 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).

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.
 • Don't do any offline validation. Just warn about it, or something. This is
   obviously not very user friendly.
 • 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.

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.
 • 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).
 • 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?

Anyway, if it turned out we need to look for the spec files for the offline
configuration, I think it would be OK to pass some search path as a parameter or
have in in configuration, or somewhere. I think having them with the
corresponding module is much better than having to hunt for it somewhere.

With regards

-- 
BOFH Excuse #430:

Mouse has out-of-cheese-error

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20120217/526d9fe8/attachment.bin>