[bind10-dev] datasources config

[Jelte Jansen]

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

On 09/22/2011 08:51 PM, JINMEI Tatuya / 神明達哉 wrote:

> 1. I suspect the data source configuration will have to be system wide
>    (like TSIG keys) rather than a spec of auth.

Yeah, though I am a bit concerned about getting too many 'global' level
things that are used by multiple modules but may be useless if you
happen to not run them at all.

> 2. Note that (at least in our current sqlite3 schema) a data source
>    may contain zones of multiple RR classes.  We provide an accessor
>    class named DataSourceClient, which is for a given single data
>    source and for a given single RR class.

Oh yes, sorry, within the current API i was only talking about
DataSourceClients, not 'full datasource'.

> 
> Considering 1 and 2, I'd envision a higher level view like this:
> 
> - there's a system-wide configuration for "data sources" (not
>   clients):
> [ { type: "sqlite3", config: some way.. },
>   { type: "inmemory", config: some way.. },
>   { type: "static", config: some way..(or maybe no config here) } ]
> - each application has its own configuration of data source "clients",
>   which is per-class (and eventually maybe per-view when we support
>   views):
> for auth
> [ { class: "IN",
>     clients: [ { type: "inmemory" }, { type: "sqlite3" } ] },
>   { class: "CH",
>     clients: [ { type: "static" } ] } ]
> for xfrin
> [ { class: "IN",
>     clients: [ { type: "sqlite3" } ] },
>   { class: "CH",
>     clients: [ { type: "static" } ] } ]
> 

Just to make sure I get the idea here, so in effect a client like auth
would see that for an IN query, it needs to check inmemory and sqlite3,
it then takes the global configs for those and sets up clients?

Not entirely sure what the use-case is, apart from more granular control
over which modules have access to which datasources. If the latter is an
important goal, i'd propose adding a 'name' variable to the datasources
config too, and referencing that at the client lists, instead of the type.


> Regarding point 3 (which is also related to how we define config for
> each data source in the above example), I guess we might want to
> provide a consistent interface, where the generic BIND 10 config only
> provides minimal level of information to get access to the data
> source, and detailed config is within the data source itself.  So, for
> example, the system-wide configuration example would be:
> 
> [ { type: "sqlite3",
>     config: { db_file: "/var/bind10/sqlite3_data_source.db" } },
>   { type: "mysql",
>     config: { server_address: "2001:db8::53",
>               server_port: "53535" } },
>   { type: "inmemory", config: some way.. },
>   { type: "static", (probably no config here) } ]
> 

This is the same as what I proposed, except for the class part.

I was thinking we might be able to provide more in-depth-but-not-online
checks by a similar structure as we currently use for tsig and logging
(i.e. a python minimodule that does some checks)

> (I'm not sure what "config" at this level would be appropriate for the
> in-memory data source - maybe we'll introduce an on-disk zone table in
> which a list of supported zones is defined with corresponding zone
> files).
> 

at this point I'm more concerned with how to specify what these things
can specify :)

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

iEYEARECAAYFAk6AKVMACgkQ4nZCKsdOncUVXQCeIPLodRBHp34qTldb8gWCFaT0
B3AAnjyG5AjQ3NB02NFruTAc08Z/2dzN
=WxMZ
-----END PGP SIGNATURE-----