[bind10-dev] issues of generic statistics spec

[JINMEI Tatuya / 神明達哉]

As discussed today's (or yesterday depending on the TZ) team call, I'm
afraid the current way of extending statistics spec is not reasonably
maintainable.  Major issues are highlighted in the case of per RR type
statistics, but I actually think it's a general issue.

In the revised spec for b10-auth in the trac2157(-2) branch, it lists
all supported qtypes to define their default (initial) values:

    "statistics": [
      {
        "item_name": "zones",
...
        "item_default": {
          "_SERVER_": {
...
            "qtype": {
                "a": 0,
                "ns": 0,
... (long lines)
                "dlv": 0,
                "other": 0
            },

and repeats this twice, once for the global default, and once for
the per-zone default.  It also defines a map entry for each RR type:
              "map_item_spec": [
                {
                  "item_name": "a",
                  "item_type": "integer",
                  "item_optional": false,
                  "item_default": 0,
                  "item_title": "a",
                  "item_description": "Number of QTYPE = A queries received"
                },
...(repeat like this for all supported types)

and defines a hardcoded array corresponding to this spec in the main
code:
const struct CounterTypeTree QRCounterQtype[] = {
    { "a",          NULL,   QR_QTYPE_A,         },
    { "ns",         NULL,   QR_QTYPE_NS         },
...(long lines)
    { "dlv",        NULL,   QR_QTYPE_DLV        },
    { "other",      NULL,   QR_QTYPE_OTHER      },
    { NULL,         NULL,   -1                  }
};

I'm afraid this will soon lead to maintenance nightmare.  Every time
we support a new type, we need to update all of these.  Also, the
mostly redundant copy of the spec defaults would easily explode as we
extend server features, such as views.

It's also difficult to apply to other modules.  It's reasonable to
assume we'd like to support one or a few types of per-RR type
statistics for the resolver.  And we'll then have to do the same
copy-paste-and-maintain dance again.

When we extend the statistics framework for DHCP, we'll face the
same problem regarding DHCP options.

These seem to suggest we need to revisit the framework at this point.
And, I don't like to defer it further; we already postponed the
discussion when we supported per Rcode and Opcode statistics.  This is
*the* time to do the right thing.

This will require some intensive design discussions.  I'm not yet
confident about how we should address this, but for a starter I'll
send a strawman proposal in a followup message.

---
JINMEI, Tatuya