BIND 10 #1213: Implement IXFR system tests

[BIND 10 Development]

#1213: Implement IXFR system tests
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  stephen
  stephen                            |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20111011
  critical                           |            Resolution:
                  Component:  xfrin  |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  7
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => stephen


Comment:

 Hello

 Replying to [comment:11 stephen]:
 > > There are bunch of really long zones. Could they maybe get generated
 (at last the long middle part) somehow instead of storing (and
 distributing) the boring part four times?
 > b10-loadzone currently doesn't support the $GENERATE directive.
 However, I have updated the files so that the "boring part" :-) is
 included via a $INCLUDE directive.

 Hmm, I didn't really know there was a $GENERATE directive, I meant a shell
 script that would generate it before the test. But this way is OK too I
 think, it both removes the duplicates and shows the differences between
 the zone versions well.

 > >This code looks long:
 > >for i in 1 2 3 4 5 6 7 8 9 10 11 12
 > >Why aren't you using seq?
 > ... because I'm rusty at shell programming.  Changed.

 Hmm, I didn't know about the nonportability. Stupid old platforms :-(.
 Should we revert it then, according to Jeremy? I wanted to propose `grep
 -q`, but it seems it's not portable as well. And I guess this is bashism?:
 {{{
 if ! grep ... | grep ; then
   :
 fi
 }}}

 > > You check only the SOA of zones transfered. Should the other data be
 also checked?
 > I was assuming that if the SOA was updated the zone had been
 transferred.  On reflection though, there is no other system test that
 checks the transfer, so I've updated the tests to perform that check.

 Nice trick, I was wondering how complicated that might be and it turns out
 quite simple :-).

 > > A lot of the named.conf and similar files are the same for multiple
 tests. Is there a chance to share them instead of keeping multiple copies?
 Git handles symlinks…
 > Good point. (I never knew that git could handle symlinks...)

 That's not so common knowledge, not many projects use it.

 > '''Other Things'''[[BR]]
 > As the current implementation of IXFR:
 > * Does not support IXFR over UDP

 Really? Hmm, surprise.

 > * IXFR-in tests requiring special programs to be written to handle the
 sending of packets to test the add/deletion order of RRs and to test the
 handling of interrupted IXFR sessions (see #1210 for details).

 I guess requiring socat is too much, right? Then we wouldn't need the
 special programs.

 Anyway, such programs would be quite simple anyway I guess.

 > In other words, close the ticket with what we have now and open tickets
 for the remaining work (in the knowledge that some of those tickets will
 be deferred until the features they test are scheduled to be implemented).

 I'm not against postponing the rest of tests until we implement the
 features, that makes sense (and splitting the task as well, it's getting
 big).

 But, few points:
  * I noticed this line:
 {{{
 return 1t
 }}}
    Is it a typo or some shell trick I don't know?
  * First line of `tests/system/ixfr/in-2/setup.sh.in` is empty. Couldn't
 it make trouble if the `#!/bin/sh` isn't at the very top?
  * The README files are indeed a way to make sure git keeps the
 directories. But AFAIK having an empty `.keep` file in the directory is
 more common way to do this. Do you think it is better to have README with
 explanation, or should we use the common way?
  * Would you merge master into this, so we can check if the test actually
 passes?

 Thank you

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