BIND 10 #1461: Implement DDNS system tests

[BIND 10 Development]

#1461: Implement DDNS system tests
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:  muks
                       Type:  task   |                Status:  reviewing
                   Priority:         |             Milestone:
  medium                             |  Sprint-20120619
                  Component:  DDNS   |            Resolution:
                   Keywords:         |             Sensitive:  0
            Defect Severity:  N/A    |           Sub-Project:  DNS
Feature Depending on Ticket:  DDNS   |  Estimated Difficulty:  7
        Add Hours to Ticket:  0      |           Total Hours:  0
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => muks


Comment:

 Replying to [comment:12 muks]:
 > Hi jelte
 >
 > 1. The config files should be formatted into multi-line ones (just like
 in the other lettuce tests). This makes both the file and future diffs
 easier to read.
 >

 oh right, i tend not to use the files directly :) done

 > 2. The following are perhaps best moved to bind10_control.py:
 >
 > {{{
 > + at step('Configure BIND10 to run DDNS')
 > + at step('Configure BIND10 to stop running DDNS')
 > }}}
 >

 ok, moved

 > 3. There's a trailing newline added at the end of example.feature.
 >

 oops, removed

 > 4. This can't be fixed, right?
 >
 > {{{
 >         # Note: test spec says refused here, system returns SERVFAIL
 >         #The DDNS response should be REFUSED
 >         The DDNS response should be SERVFAIL
 > }}}
 >

 I think it can, but it would be out of scope for this ticket.

 > 5. DDNS_RUNNING should perhaps be changed to DDNS_STARTED to make it
 consistent with other *_STARTED ids. This is a lettuce ticket, but maybe
 you can throw that in as it's a minor change and used here anyway.
 >

 Yes, tests like these make such things quite obvious, don't they :)

 I originally considered it out of scope as well, but it's too small to
 spend a new ticket on, changed.

 > 6. If `prepare_update()` accepts a zone name, maybe `set_serial_to()`
 should too.. but up to you :)
 >

 easy to add if we want it, skipping for now

 > 7. Does this sequence log any messages to indicate that the ACL was
 updated? If so, we should wait for it to avoid a race. If not, we should
 log and wait for it.
 >
 > {{{
 >         # Test 4
 >         When I send bind10 the following commands
 >         """
 >         config add DDNS/zones
 >         config set DDNS/zones[0]/origin example.org
 >         config add DDNS/zones[0]/update_acl {"action": "ACCEPT", "from":
 "127.0.0.1"}
 >         config commit
 >         """
 > }}}
 >

 nothing is logged at this point, but commit shouldn't return before the
 module has processed the update anyway, so I do not think we can have a
 race here. We might still want to add a lowlevel debug statement for
 administrators convenience, but I do not think it is necessary here (so
 I'm considering this out of scope for at least this ticket, feel free to
 suggest it as an enhancement).

 > 8. Even here, it would be good to doubly check any log message output by
 b10-ddns for the update. The `nsupdate` return is sufficient, but the log
 check would indicate our code in the particular handler was invoked and
 also avoid a race with `nsupdate`.
 > {{{
 >       # Test 5
 >       When I use DDNS to set the SOA serial to 1237
 >       The DDNS response should be SUCCESS
 >       And the SOA serial for example.org should be 1237
 > }}}
 >

 I've added one that could in theory be a problem right now (and fixed a
 test prerequisite; the module tests were supposed to serve the zone from
 memory loaded from db); it does wait for the message that the zone has
 been reloaded into memory. In all the other cases I again think that there
 should be no race; ddns wouldn't respond until the transaction was done.
 (also, I don't think there is a separate 'ddns handled and done, all good'
 log message, unless you count DDNS_UPDATE_NOTIFY. Same as for updating
 acl; feel free to suggest enhancement :)

 > 9. Is DDNS restarted automatically after the shutdown? In this case,
 please add a comment between the two lettuce statements:
 > {{{
 >       # Test 6
 >       When I send bind10 the command DDNS shutdown
 >
 > +       # Perhaps add this too:
 > +       And wait for new bind10 stderr message DDNS_STOPPED
 > +
 > +       # DDNS is now automatically restarted by BoB.
 > +
 >       # Test 7
 >       And wait for new bind10 stderr message DDNS_RUNNING
 >
 > }}}
 >

 ok, added

 > 10. Is this due to a race in the next lettuce command getting to DDNS
 before it's ready?
 >
 > {{{
 >       # Test 8
 >       # Known issue: after shutdown, first new attempt results in
 SERVFAIL
 >         When I use DDNS to set the SOA serial to 1238
 >       The DDNS response should be SERVFAIL
 >       And the SOA serial for example.org should be 1237
 > }}}
 >

 No, it has to do with the communication from auth to ddns, see
 http://bind10.isc.org/ticket/1460#comment:9

 > 11. Same as item 9 here:
 > {{{
 >       # Test 9
 >       When I send bind10 the command Auth shutdown
 >       And wait for new bind10 stderr message AUTH_SERVER_STARTED
 > }}}
 >

 added

 > 12. Does `update_acl` allow IP addresses only? Are hostnames not
 allowed? Also, why is it called `update_acl` and not just `acl` ? (Sorry
 about the silly questions, but I'm asking out of ignorance).
 > {{{
 > @step('set DDNS ACL ([0-9]+) for ([0-9.]+) to ([A-Z]+)')
 > def set_ddns_acl_to(step, nr, address, action):
 > }}}
 >

 I don't know, I just write the tests ;)

 I suspect it is because it may at some point be converged with other
 acl's, and hence need to be clearly differentiated from, say, query_acl
 (and/or to make it at least sound a bit like the corresponding bind 9
 value).

 localhost probably also works, but i tend to prefer 127.0.0.1 over
 localhost, tbh :)

-- 
Ticket URL: <http://bind10.isc.org/ticket/1461#comment:13>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development