[bind10-dev] Configuration, bindctl, etc.

[Michal 'vorner' Vaner]

Hello

On Tue, Mar 26, 2013 at 03:27:04PM +0100, Jelte Jansen wrote:
> - wrap actual data in a new class which provides access to:
> 	- the 'raw' data
> 	- the specification part of this data
> 	- the 'parent' of this data (if any) (or at least the relative
>           location)
> 	- the 'children' of this data (if any)
> 	- the 'name' of the element (if applicable) that contains this
>           data

On one side, it looks good. But, we should make it so we don't get lost in bunch
of calls to getters. It was kind of nice to be able to just use the raw data in
python.

We could either make the wrapper act like them (eg. inherit from python dict, or
something like that), or have a method to return the data structure as raw data
(recursively).

> Then we should probably define a way to codify 'differences' (there was
> a proposal somewhere for a format), and wrap those in classes as well;
> and then add generate, check and apply methods to the class above, and
> update config handlers to work with them.

Would this be handled in isc.config.ModuleCCSession, or in the handler itself?
On one side, it would be nice to just pass the final data to the handler as we
do now, so it wouldn't have to do some apply magic, on the other side, sometimes
it might be useful to know what changed. We might want to pass both.

>     Another approach would be to make the current 'plugin' system in
>     cfmgr more of a first-class citizen, and allow these for normal
>     modules as well (so when you write a module, you can additionally
>     provide a small python file to do config checks).

+1 on this.

The current system has another problem that would be solved by this. It is
unclear what happens when there are multiple instances of one module. If the
check was done by plugin and then only a notification („there's new data, use
it“) was sent, the problem was gone.

>     And a third would be very wild I guess; we change components not to
>     be executables but dynamic libraries, with a few well-known
>     methods, such as 'run' and 'check-config'.

That sounds like nice idea. Though, this kind of generic plugin system would be
something to consider in year one, probably not now.

> - custom types
>     I think that we should have more than just raw types; IP addresses
>     come to mind instead of strings, but also zone names, etc. The
>     immediate advantage is that (like for offline config), these are
>     pretty well-defined and easy to verify.
>     A second level of this would be extensible types; compound types
>     that could be reused.
>     Another advantage is that user interfaces could make use of this
>     info to make them more userfriendly.
>     An addendum to this is that with it we should be able to make
>     recursive types, and not have to deal with the 'any' thing we have
>     now for ACLs etc.
>     Currently this is hard to add because of the way raw data is parsed
>     and handled, but given the earlier changes I think this can finally
>     be added.

Slightly related to this, I'd like to have a way to plug one config somwhere
into the hierarchy of another. Analogous to how unix mount works, compared with
windows letters for drives.

It would be nice for a hook/plugin for auth, to have the configuration in the
Auth/ config, and not somewhere else separately.

> - also related to the previous two perhaps, but we need to extend the
>   specification 'language'.
>     For starters, it might need a bit of context sensitivity (option B
>     can be either X or Y depending on the value of option A, e.g.
>     datasources config).
>     Related to the first one, perhaps we can add some basic rules (also
>     something suggested a long time ago, for instance for integers
>     specify a valid range, for strings specify a regex that should
>     match, etc.). This might also be a good time to reconsider whether
>     JSON is a good format for the .spec files themselves.

I think we need to be careful here little bit. We don't want to be solving
dependencies of variables (recursively) or so.

Also, I don't know about the format. If we have in-house language for spec
files, then JSON is probably as good as any other, and our system handles it
„natively“. I don't think sending a XML document over the MSGQ as string would
be the best thing to do.

It may be worth looking if there's any already created language for the
specifications, though.

With regards

-- 
There is one difference between linux and windows.
With windows, you pay for the software, but you get all the T-shirts for free.
With linux, you get all the software for free, but you buy the T-shirts.

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/20130327/97aa6b7e/attachment.bin>