[bind10-dev] addZone interface for the new loadzone and zone management framework

[Michal 'vorner' Vaner]

Hello

The last problem first, since I see a reasonable solution:
> Another note related to the topic (but basically orthogonal to the
> previous point): if we separate the operation of adding a zone and
> the operation of loading zone data (e.g, not within the same DB
> transaction), there will be a period when a server recognizes the
> existence of a zone without its content.  Then, until the load is
> completed the auth server will return SERVFAIL to queries for the
> zone.  This is probably not the wanted behavior, and I guess we'll
> need to provide some way to make both operations atomic.  It will
> probably affect some of the interfaces we are currently developing.

I think the addZone should directly return the updater. Or, the getUpdater
should have a „bool can_add“ parameter. That way, the zone is not really there
until we commit the updater, which is what we want.

On Wed, Dec 05, 2012 at 08:38:52PM -0800, JINMEI Tatuya / 神明達哉 wrote:
> In the short term, we need to decide whether to take this path or add
> some sqlite3-specific quick hack to the loadzone code itself.  If we
> choose the former, we should probably lower the priority of some of
> the existing tickets of the sprint.  Possible candidates would be:
> #2500 (SOA RDATA support), #2440/#2441 (merge/order-free load for
> in-memory).

I'd like to note first how I dislike our „short term quick hacks“. It seems our
„short term“ is very long and we seem to spend very much time implementing
short-term hacks we throw away later. It makes the code quality lower and makes
our progress slower (we sometimes gain some short-term advantage like having a
feature available for release, but I don't know if it's worth it).

In this sense, I think the addZone approach is slightly better. Optimally, we
would have the discussion about how to store and manage zones first (which we
failed to have for some long time now already), but I understand it's not
possible at this stage.

> For a longer term, I think this is related to how we manage zones in
> data sources and how to implement it, including deleting/listing zones
> and supporting zone related configurations (primary vs secondary, list
> of primary servers in case of secondary, zone specific ACL, etc).
> Personally, I don't believe the JSON style configuration data are
> sufficiently scalable to support such information for millions of
> zones, and that should go to a separate (conceptual) database.  And,
> for real DB-based data sources, it would be natural to store this
> information in the same DB as that stores other zone data.  If we take
> this approach, I suspect the feature set of managing zones will be
> beyond the scope of the concept of data source client, and
> implementation-wise we'll need another class.  As such I'm personally
> a bit reluctant to do #2541 at this point, but of course this
> discussion is debatable in the first place.

This probably will want a wider discussion (and possibly a separate thread,
proposals, etc). But from the look at it, I don't like the database approach for
several reasons:
 • JSON is much more flexible. It allows things like nesting, which is very hard
   in DBs (all ways to do so are simply hacks).
 • It'd be very confusing. Some of the configuration would be in the JSON,
   accessible through bindctl. Some other would be in various databases,
   accessible through different set of bindctl commands (in the better
   situation), or through the dabatase only.
 • We face the problem of what happens if someone modifies the database and
   doesn't tell us again, on another level. And what do we do if the ACL in DB
   is broken? We didn't have an opportunity to reject it as invalid before.
 • Every single one data source will have to implement it again and again and
   again.
 • What do we do with „volatile“ data sources, like in-memory? We already have
   more exceptions to it than we would need. This would require even more (and
   not only in implementation, but in the interface to users too).
 • Do we really want to create yet another representation of ACLs with full
   support of any checks, nesting, etc? And force administrators to learn them?
 • Your scalability observation is based on current implementation of our JSON
   handling, not on the JSON format itself.
 • Databases are not human-readable. In case of database backup or something, it
   does not really help.

So, I'd like to keep it in the JSON as it is, but do it right this time
(incremental updates, using named sets, not lists, etc). And, of course, design
the structure so it is convenient to users (and not scattered over the
components).

With regards

-- 
The problem with graduate students, in general, is that they have
to sleep every few days.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20121206/83692a7a/attachment.bin>