[bind10-dev] MSGQ-NG requirements

[JINMEI Tatuya / 神明達哉]

At Tue, 10 Apr 2012 15:26:25 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > Whether this (both speed and scale) matters depends on for what and
> > how we want to use it.  Are we assuming we'll pass a list of the 1
> > million zones with additional per-zone configuration via msgq?  What
> > if the zones are primarily configured in a database backended data
> > source?  What about ACLs, especially if they are defined per zone?
> 
> Well, if we couldn't pass our configuration and all this we pass
> through it now, the msgq would be pretty useless.

I do not necessarily think so (while I agree that it's convenient if
we can assume a single interface with the ability of passing any
amount of complicated data).  In an extreme end of this approach, we
could even store zone's RRs as part of "configuration" and pass them
over msgq.  But I don't think anyone say it would be "pretty useless"
if it couldn't be used for that purpose.  So, it's a matter of the
balance between the convenience of using a single unified tool and its
cost.

> > I'm not necessarily insisting that's the definite way to go, but
> > apparently we are having different images of applicability on msgq.
> > It may also differ for others.  So I think it's important we first
> > establish a shared image of the intended usage of msgq with a highly
> > scalable operational environment. 
> 
> I don't know. Maybe we don't want to pass the full list of zones, if
> they are in a database, and we don't want to send the whole
> statistics, only a diff. But we probably do want to send ACLs (where
> would the reside except for the config manager?) and if the data
> source needs the list in its configuration (in-memory, having each
> one loaded from some file or other data source), so I think we
> should be able to send some large messages. I think we might get
> away not being able to send tens of thousands of messages per
> second, on the other hand.
> 
> But anyway, this might be one thing to discuss during the F2F or
> some call, if there's time.

I think that would be pretty useful.  We can discuss several specific
cases, like

- millions of zones
- per zone statistics, especially for such cases
- thousands of ACLs, some may be global, some may be zone specific,
  and there may be millions of such zones

and where/how we configure them, pass the configuration information to
relevant processes, update all or part of the configuration, taking
into performance and other implications.

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