[bind10-dev] datasources config

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I've been looking at the datasource factory function for #1206, and what
i'm currently running into is how we would configure them

Problem statement

We have several types of datasources, and for each type the
configuration will differ. Ideally, the configuration should be
available in the 'main' module spec, so that cfgmgr can validate it, and
bindctl can use completion and examples. This would need to be
extensible, for other datasources, and perhaps should not directly
expose all options for datasources that are not in use.


Idea

A way to go is to have 'one-of' maps; depending on the value of the
name, the map specification can be different. We could then have a list
of those maps as the data source config.

For example, let's say we have three datasources we want to use. One of
them is the CH 'static' ds, which takes no config at all. One of the is
the sqlite3 backend, which needs a DNS class and a database file (the
contents of the dabase will define which zones it contains), and one of
them is the in-memory database that needs a class, and a list of zones,
each which consists of an origin and zone file names.

Starting out with a config of no datasources (for the purpose of this
example), I envision it to work something like
> config show datasources
/Auth/datasources []
> config add Auth/datasources static
> config show Auth/datasources
/Auth/datasources/static
> config describe Auth/datasources/sqlite3
Item name                          type      default value
/Auth/datasources/sqlite3/class    string    "IN"
/Auth/datasources/sqlite3/file     string    "/foo/bar/zones.db"
> config add Auth/datasources sqlite3
> config show Auth/datasources
/Auth/datasources/static
/Auth/datasources/sqlite3/class  "IN"
/Auth/datasources/sqlite3/file   "/foo/bar/zones.db"
> config add Auth/datasources memory
> config show Auth/datasources
/Auth/datasources/static
/Auth/datasources/sqlite3/class  "IN"
/Auth/datasources/sqlite3/file   "/foo/bar/zones.db"
/Auth/datasources/memory/class   IN
/Auth/datasources/memory/zones   []
> config add Auth/datasources foo
Error: Unknown datasource type 'foo'

On the specfile side, this would need a new type, and preferrably, some
form of include specpart statement (i.e. include all
datasource_<name>.spec files, and make the compound one-of map out of them).

This does have the problem that we would only be able to use one of each
type of datasource. If we want to support having more than one, a slight
abstraction needs to be made. For instance, we could make the list a
list of maps that have a name, a type, and a submap with the
type-dependent config.
> config show Auth/datasources
Auth/datasources []
> config add Auth/datasources my_db
> config show Auth/datasources
Auth/datasources/my_db/type ""
Auth/datasources/my_db/config {}
> config set Auth/datasources/my_db/type sqlite3
> config show Auth/datasources/my_db
Auth/datasources/my_db/type "sqlite3"
Auth/datasources/my_db/config/class "IN"
Auth/datasources/my_db/config/file "/foo/bar/zones.sqlite3"

If this is the only use-case for such a construct, perhaps we can even
skip the 'config/' subpart, and make it a 'type-dependent' map that
always has a fixed-name 'type', from which the rest of the map
specification is derived. I.e. it would be a combination of these two ideas.


Some other thoughts

Recently I added the 'named set' type to config options, and for that it
already became quite clear that we are running into the limits of what
we can do with the current way of handling config and specs. Major
initial problem is how everything is directly based on the low-level
types returned by the JSON parser(s). I'll try to come up with a
proposal to address this too (also keeping the above in mind).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk56+2MACgkQ4nZCKsdOncUSNgCguzcUWe/MV48RfOJHtoSiFrAs
8fUAniSdgQCxXaIFvqU4bD01O3ldQsy3
=hmtE
-----END PGP SIGNATURE-----