BIND 10 #1288: Update XFROUT to use new interface

[BIND 10 Development]

#1288: Update XFROUT to use new interface
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20111122
                  Component:         |            Resolution:
  xfrout                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:20 vorner]:

 > > >  * More to the workaround itself, we now have two with the same
 workaround, with more to expect, probably? Would it be better to just pass
 the environment variable to anything started? Other things shouldn't be
 hurt by it anyway and it would remove two specials, making it easier for
 the user. Or, should we try talking about it tomorrow at the call?
 > >
 > > Apparently #1292 was resolved (I've not closely checked the solution
 > > though).  So we can probably just merge and then cleanup the
 > > intermediate hacks for xfrin/out (but I'd defer the cleanup task to a
 > > separate ticket as this ticket could be a blocker for the IXFR-out
 > > support; I'd rather merge this branch first).
 >
 > I'd like to see it resolved before the release, otherwise the user will
 have to reconfigure after we remove the special components. I don't care
 if in a separate ticket or not, though. How large do you guess it will be?

 It won't be too large, but that will be a system wide change and not
 really specific to xfrout (xfrin will also need to be updated), so I
 think it's a topic of a separate ticket.  I don't see the point of
 "will have to reconfigure" part, too, in the context of whether to
 merge this ticket; first off, if the cleanup requires the user to do
 something, we already have this problem due to xfrin, so that means
 whether or now we merge this branch the issue would have already
 existed.  second, I really don't understand what the user "will have
 to reconfigure".  Right now, the special hack for xrin/xfrout are
 hardcoded in the bob.spec and the source code, so, basically as long
 as the user re-install everything and not heavily customize the
 component settings such as specifying a special priority for
 xfrin/xfrout (which I suspect is quite unlikely at least for a while),
 the change should be transparent.

 I'll see haw easy/difficult to make the cleanups anyway, but I still
 prefer not delaying for merging this branch just for that reason.

 > Is it possible the Makefile in xfrout test needs that too? Because of
 this failure?

 Ah, yes, probably.  I updated Makefile.am for xfrout/tests, too.

 > Anyway, this error might show that it doesn't send even SERVFAIL. Is it
 possible?

 That's what the original code does, but it would make more sense to
 return SERVFAIL in such a case.  I've updated the source to do it.
 (I slightly hate to add more special cases in an ad hoc manner like
 this, but as we repeatedly discussed we'll need heavy overhaul of xfr*
 eventually, and I hope we can make it cleaner at that point)

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