[bind10-dev] Enabling the user interface

[Shane Kerr]

All,

This is a little abstract, but comes out of some discussion of how to
allow the folks working on the user interface (CNNIC) to move forward
while the actual configuration component is not yet done.


Basic Configuration
--------------------

The details about the configuration stuff are still unknown. But
basically it will consist of a hierarchical set of attribute/value
pairs, as described in Jelte's "configuration experiment" e-mail:

https://lists.isc.org/pipermail/bind10-dev/2009-September/000099.html

The operations on these pairs will be basic CRUD:

http://en.wikipedia.org/wiki/Create,_read,_update_and_delete

"read" includes getting a list of which attributes are available.

We will also need transactions. This is because a set of attributes may
make no sense unless you do it in a set. For example, adding a zone
means you need to say whether it is a slave or a master, and if it is a
slave you need to know the IP addresses of the masters, all at one time.

Ideally we will also have versions. This means the ability to revert to
earlier versions of configuration. "Reverting" is likely to be more like
the Wikipedia - applying as much as possible from an old version. This
is because it is rarely possible to actually go backwards with a running
system.


Configuration User Interface
----------------------------

I expect the user interface to BIND 10 will allow administrators to set
these attribute/value pairs. So, you will be able to add a master to a
server by doing something like:

> get auth/zones/example.org/masters
192.0.2.1 192.0.2.2

> set auth/zones/exapmle.org/masters="192.0.2.1 192.0.2.2 192.0.2.3"
attribute "auth/zones/exapmle.org/masters" does not exist

> set auth/zones/example.org/masters="192.0.2.1 192.0.2.2 192.0.2.3"
attribute "auth/zones/example.org/masters" set

There are advantages of such a configuration and user interface
mechanism:

      * It allows a new component to be added without having to change
        the user interface tool(s). This is important to allow people to
        change BIND 10 to meet their needs without having to do a lot of
        work.
      * Writing the user interface is very simple. Only a very small set
        of operations is needed ("list", "add", "get", "set", "remove").

However, while this is infinitely flexible, it is also relatively clumsy
and hard to use.

It also does not support a number of non-configuration related commands
that will be necessary. For example, starting/stopping the server,
requesting a fresh zone AXFR from the master, or re-signing a zone.


Towards a User Interface
------------------------

We need two things:

     1. A way to define sets of configuration changes that are more
        natural to the administrator.
     2. A way to define non-configuration actions.

I think it makes sense to define "administrator actions".

Each component can define as few or as many of these as necessary. This
would probably be done in a configuration file (which will end up being
XML at some point, although maybe not written as such).

So we may have something like:

        Action: AddMaster NAME DATA_SOURCE [ACTIVE=False]
        Description: Add the zone. Unless specified, the zone is not
        served until activated.
        
A component will define these, then the UI will get them at runtime
(either from the component itself or from a central configuration
component).

The UI can then tell the user what actions are available, and give the
user details about the syntax and meaning. It can deliver the request
for an action using the c-channel, and the component will then have all
the information it needs, syntax checked. The result will be returned
using the c-channel.


That's the basic idea. It has some rough edges (clearly), so feel free
to point out problems or propose alternate solutions.


For example, it may make sense to arrange actions so that they are
grouped:

> add zone example.info type=master data_source=zone_file:/var/bind10/db.example.info
> add zone example.net type=slave masters=192.0.2.1,192.0.2.254
> add zone example.com type=master data_source=sqlite:/var/bind10/sqlite.example.com

Here we make a single action for adding all types of zones, with
different data sources. These all involve different parameters. I am not
sure the best way to define this.

--
Shane