<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
First, I want to introduce Paul Ebersman to the kibitz team. Paul is a
meek person with no history of causing problems (not!) Paul is the only
person I know to have almost tested the UUNet rule: "if you kill
someone, you have to do their job and yours." I think it is fair guess
that Paul has more ISP ops time than the rest of us combined, much of
it causing trouble. Thus he is a perfect candidate to the kibitz team.
He also works for ISC doing remote support and consulting to ISC
support customers, so he can give us some different perspectives.<br>
<br>
Paul, besides Brett the list has Marc Evans and Ben April. I met them
on the "base" project for Trend. Marc is at a startup doing reputation
service and has a long history with open source (led the XFree86 team
for many years.) Ben was the ops tool geek at Globalnet at one point
and is doing threat research for Trend.<br>
<br>
<br>
This is an email I posted to the BIND 10 developer's list. This is
their first introduction to the idea of different management data
abstractions in a practical application. Any thoughts from the
kibitzers?<br>
<br>
thanks,<br>
jerry<br>
<br>
-------- Original Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">Subject: </th>
<td>Re: [bind10-dev] How to organize zone config items in bind10?</td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">Date: </th>
<td>Fri, 27 Aug 2010 08:56:48 -0700</td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">From: </th>
<td>Jerry Scharf <a class="moz-txt-link-rfc2396E" href="mailto:scharf@isc.org"><scharf@isc.org></a></td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">To: </th>
<td><a class="moz-txt-link-abbreviated" href="mailto:bind10-dev@lists.isc.org">bind10-dev@lists.isc.org</a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>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
> <a class="moz-txt-link-abbreviated" href="mailto:bind10-dev@lists.isc.org">bind10-dev@lists.isc.org</a>
> <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind10-dev">https://lists.isc.org/mailman/listinfo/bind10-dev</a>
>
</pre>
</body>
</html>