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      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => jinmei


Comment:

 Replying to [comment:11 jinmei]:
 > First off, the test did not always succeed (but sometimes it
 > succeeded).  I often saw this:
 >
 <snip>
 >
 > (This exception itself seems to be a kind of bug but that aside) This
 > seems to suggest that b10-xfrout did not fully start up when the IXFR
 > query was made.   If that always succeeds in your environment, maybe
 > you can try it with adding some intentional delay (e.g.) between
 > these:
 >
 > If my guess is correct, maybe we'll need something similar to
 > wait_for_auth.
 >

 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.

 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.

 > Second, I made a couple of editorial fixes and pushed them.
 >

 Thanks

 > '''lettuce/README.tutorial'''
 >
 > (not a subject of this ticket but I first read the READMEs to
 > understand the test and noticed these)
 >
 > - is this a typo?  The first 'no' should be removed perhaps?
 > {{{
 > The one scenario we have no has no steps,
 > }}}

 yes, fixed.

 > - s/fire of/fire off/?
 > {{{
 > This is not good enough; it will fire of the process, but setting up
 > }}}
 >

 ack. Made it 'it will start the process', btw.

 > '''transfer.py'''
 >
 > I didn't understand what kind of magic was used for 'step.multiline'
 > {{{#!python
 >     expect = re.sub("[ \t]+", " ", step.multiline)
 > }}}
 > but with common sense it looks okay.
 >

 It's a bit of a weird construct to pass longer sets of data to the
 function; if it reads a three quotes, the value is passed into the step's
 multiline member (also see http://lettuce.it/tutorial/multiline.html but
 that mostly talks about whitespace problems).

 Typing this I realize we could perhaps also implement this using tables,
 but the way to get to that data is pretty similar
 (http://lettuce.it/tutorial/tables.html)

 > '''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)

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