BIND 10 #1314: IXFR-out system tests

[BIND 10 Development]

#1314: IXFR-out system tests
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  stephen                            |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20111220
                  Component:         |            Resolution:
  Unclassified                       |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  7
Feature Depending on Ticket:  IXFR-  |           Total Hours:  5
  out                                |
        Add Hours to Ticket:         |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:13 jelte]:
 > Replying to [comment:11 jinmei]:
 > > First off, the test did not always succeed (but sometimes it
 > > succeeded).  I often saw this:

 > Ack, added a similar 'wait for xfrout' step. We could already do this
 through a 'normal' wait for stderr output, but it seems cleaner to have a
 separate step. And I'm not entirely happy with the line it now waits for
 (XFROUT_NEW_CONFIG_DONE), but xfrout doesn't log something like 'I am now
 done, and running'. Perhaps we should have those in all modules as some
 info or debug statement.

 Yeah, and I think we need more generic and reliable way to confirm
 that a component is fully ready, not only for tests.  For example, I
 guess b10-auth would like to know whether xfrout/ddns is really active
 rather than just naively passing requests to the corresponding UNIX
 domain socket (and possibly getting an exception subsequently).

 One thing we could do for tests would be to implement the 'ping'
 command for all components.

 Anyway, that will be beyond the scope of this ticket.

 > Can you see if it now works consistently? I expect the error is caused
 by killing the rest of the system while a module is starting up. But yeah,
 if so, we should probably present some nicer output there.

 Yes, it now succeeds constantly.

 (Some other tests still fail, btw,
 {{{
     A query for www.example.org to 127.0.0.1:47807 should have rcode
 NOERROR                       # features/terrain/querying.py:183
 ...
     AssertionError: Expected: NOERROR, got NO_ANSWER

     Then wait for new bind10 stderr message XFRIN_XFR_TRANSFER_SUCCESS not
 XFRIN_XFR_PROCESS_FAILURE             # features/terrain/steps.py:34
 ...
     AssertionError: Timeout waiting for process output:
 [u'XFRIN_XFR_TRANSFER_SUCCESS', u'XFRIN_XFR_PROCESS_FAILURE']
 }}}

 "NO_ANSWER" and "timeout" seem to suggest the same thing might be
 happening?  (again, would be a separate issue though).

 > > '''ixfr_out_bind10.feature'''
 > >
 > > I have to admit I've not read the commented out tests.  The enabled
 > > tests seem to be okay (except that they didn't always succeed as
 > > discussed above).
 >
 > Ok. Well, they are commented out anyway (which is really not following
 the yagni principle, but I suspect having them ready when we do udp will
 be very nice, even if we don't end up using all of them, at least we'll be
 forced to realize that)

 I've now quickly looked at others a bit more closely.  Some comments:

 - What's the difference between Scenario 1's tests 1 and 2?
 - I guess many of the tests can be done successfully over TCP and
   wonder we should actually do it?

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