[bind10-dev] Idea for simple (but limited) views

[JINMEI Tatuya / 神明達哉]

At Wed, 12 Jun 2013 10:22:03 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> But if we restricted ourself to just one scenario ‒ providing different zones
> for different clients, there's an easy solution (I'd guess something like 2 or 3
> tickets would do it, once we switch to the newer configuration in all the
> XfrIn/XfrOut/ZoneMgr…).
> 
> The idea is, we won't provide different zones to the different clients, but
> different data sources. They can contain different zones or just the same zones
> with different content. It is possible to have multiple copies of the sqlite3
> data source and if that would be deemed too heavyweight, I have a proposal for
> that below.

I think it primarily depends on the ever lasting question of for which
purposes we provide views.  If what most, or at least a large size of,
users (of views) want is to merely return different zone data for
different clients, it may make sense to focus on that feature of
views.  If it's more generic, like using RRL for one view but not for
other, we'll have to at least take into account extendibility towards
that goal, even if we begin with the limited form of views.  After
asking for the user need unsuccessfully for several years, I simply
don't know the answer yet.

But, assuming we can safely focus on data-only views for now, it seems
to make sense to consider how we can realize it through extensions to
the data source API, keeping the work load reasonably lightweight.  As
you said the balance between the feature and available development
resource matters, but at the moment I personally feel it's ad hoc to
incorporate the concept of the views directly into the ClientList,
because it will mix the current policy of data source selection
(basically trying one by one in the list order) and the new policy of
view matching, making it more difficult to understand and causing many
corner cases.

So, while this will require more extensions, I'd be inclined to
introduce the views into the data_sources configuration explicitly,
with corresponding data structures (or classes).  This would revise
our current data_sources config:

"data_sources":
 {"classes": 
  {"CH": [{"type": "MasterFiles", "params": {"BIND": "/somewhere/static.zone"},
           "cache-enable": true}],
   "IN": [{"type": "sqlite3",
           "params": {"database_file": "/somewhere/zone.sqlite3"}}]}}

It would look:
"data_sources":
 {"classes":
  {"CH":
    {"views":
      [{"name": "builtin",
        "match-clients": <ACL-spec or something>,
        "sources":
        [{"type": "MasterFiles", "params": {"BIND": "/somewhere/static.zone"},
          "cache-enable": true}]
       }
      ]
     }
  },
  {"IN":
    {"views":
      [{"name": "internal",
        "match-clients": <ACL>,
        "sources":
	[{"type": "sqlite3",
          "params": {"database_file": "/somewhere/zone-internal.sqlite3"}}]
       },
       {"name": "external",
        "match-clients": <ACL-any>,
        "sources":
	[{"type": "sqlite3",
          "params": {"database_file": "/somewhere/zone-external.sqlite3"}}]
       }
      ]
     }
    }
  }

Then, the parsers of "data_sources" configuration
(auth::configureDataSourceGeneric() or Python DataSrcClientsMgr)
will create a list of new "DataSourceView" class objects, instead of
ConfigurableClientLists directly.  A DataSourceView internally builds
a ConfigurableClientList object corresponding to that view.

Applications will maintain a map from RR classes to DataSourceViews,
and first identify the best matching view for the RR class, and then
use the corresponding ConfigurableClientList.

Finally, whatever approach we take, there will be still some non
trivial issues such as how to configure zone transfer for the same
name of the zone belonging to different views.  It should be sorted
out at the design phase.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.