[bind10-dev] How to organize zone config items in bind10?

[Jerry Scharf]

Shane,

In my thinking, the modules should carry the configuration data that 
they need and that it is the idea of the front end to take something 
like a BIND 9 config file or other abstract form and chop it up as the 
modules need it.

There are three areas of thinking that lead me to this opinion:

Though it may sound strange, I consider BIND 9 config files (and rndc) 
to be the 'user interface' of BIND 9. I see different people wanting 
different user interfaces to BIND 10. One is to run with the BIND 9 
interface. A second is to use someone's existing management tool like 
infoblox. A third way is to use what we are considering for the BIND 10 
command tool. Each of these has a different model for the data and 
metadata (config elements are the obvious form of metadata.) This leads 
one to the question "do we put all these different models in the server 
configuration, pick one or don't put any of these in the server 
configuration itself?" Being a lazy designer, I naturally lean toward 
not putting any of them in the server itself.

I think this becomes more clear when I think through what extensibility 
requires. As others begin to replace and add modules to the server, they 
are going to create new configuration needs. They may also choose to 
reconfigure the configuration elements that the BIND 10 team allocate in 
our modules. Trying to keep all this straight within the server itself 
seems sure to cause problems. The new module designers may not even 
support their modules with the BIND 9 user interface, you use their 
management interface with servers running their modules.

Finally, it comes from my view that the server is designed to run at 
network speeds using efficient local data. Management tools are designed 
to run at human speeds using human concepts. The BIND 9 user interface 
is a compromise of the two and can cause problems for each side.


If we concentrate the problem of translating upper level models to the 
exact requirements of the modules in the management layer, new modules 
are much more able to create and refactor configuration elements to 
their need.

In Likun's case, I see the 'also notify' section for zone X should being 
stored in the xfrout module section and in a form that xfrout wants it.

This does put more burden on the command tool, BIND 9 emulator and the 
like, but I believe it is the best route. A new module requires the 
associated management functions for its "care and feeding." It also 
requires documentation of the configuration needs of a given module at a 
level that someone can read the documentation and successfully translate 
their management data model into correct control of the server module. 
Good design on these configuration structures will make many friends. :)


Do others agree with this? Are there better ideas out there?

warmly,
jerry

On 08/27/2010 05:59 AM, Shane Kerr wrote:
> Likun,
>
> On Tue, 2010-08-03 at 21:10 +0800, ZhangLikun wrote:
>    
>> There are several config items for one zone,  master_addr, also_notify,
>> allow_update, etc.  Since the items are used by different modules, so it
>> makes sense to distribute these config items to different modules, like:
>>
>> Xfrin has config item: master_addr
>> Xfrout has config item: also_notify
>> Update has config item: allow_update
>>
>> And bind10 also need one "zone_list" config item, to make clear which zones
>> bind10 is servicing, my suggestion is let config manager module hold the
>> config item 'zone_list'.
>>
>> My question is : does it need to let config manager hold all the config
>> option for one zone? So that the duplicated zone list information can be
>> avoided in xfrin, xfrout and other modules. Like, config manager will have
>> the config data like:
>>      Zones :  [
>> 	 { 'cn' :  [  {  ' master':  [master_list]  },
>>                 {  'also_notify' :  [notify_slave_list]  },
>>                 {  'allow_update' :  [address_list]  },
>> 		      .... some_other_options....
>>              ]
>>
>>        'com'  :  [  ...zone's_options.... ]
>>        'net' :  [  ...zone's_options.... ]
>>       }
>>
>> Any suggestion?
>>      
> Hopefully I did not miss a discussion about this. :-P
>
> In any case, avoiding duplication makes sense to me. I think it is okay
> for modules to use configuration for "other" modules, as long as this is
> done in a controlled way.
>
> --
> Shane
>
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev
>