BIND 10 #2064: components "kind" needs to be specified explicitly even for default

[BIND 10 Development]

#2064: components "kind" needs to be specified explicitly even for default
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |                       Status:  new
            Priority:  medium        |                    Milestone:  New
           Component:  Unclassified  |  Tasks
           Sensitive:  0             |                     Keywords:
         Sub-Project:  Core          |              Defect Severity:  N/A
Estimated Difficulty:  0             |  Feature Depending on Ticket:
         Total Hours:  0             |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
 {{{
 > config add Boss/components b10-ddns
 > config show Boss/components
 ...
 Boss/components/b10-ddns/special        null    string
 Boss/components/b10-ddns/process        null    string
 Boss/components/b10-ddns/kind   "dispensable"   string  (default)
 Boss/components/b10-ddns/address        null    string
 Boss/components/b10-ddns/params/        list
 Boss/components/b10-ddns/priority       null    integer
 ...
 > config commit
 Error: 'kind'
 Configuration not committed
 > config set Boss/components/b10-ddns/kind dispensable
 > config commit
 (succeeds)
 }}}

 This is confusing at best.

 Another matter, piggybacked: it accepts it even if "address" is
 unspecified.  But without this the bind10 process cannot tell ddns
 a shutdown and needs to fall back to SIGTERM.  This is also not good.

 p.s. Frankly, I'm reluctant to fix each and every one of such peculiar
 thing one-by-one.  This seems to be a general issue of the
 config/bindctl framework.  If we have a clearer definition of which is
 default, which is mandatory, relationship "optional" vs "default" etc
 and provides generic framework based on it, this kind of thing should
 be automatically avoidable by the framework and the spec definition.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2064>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development