BIND 10 #389: Configuration of b10-recurse trough the config manager

[BIND 10 Development]

#389: Configuration of b10-recurse trough the config manager
-------------------------------+--------------------------------------------
      Reporter:  vorner        |        Owner:  jelte    
          Type:  enhancement   |       Status:  reviewing
      Priority:  major         |    Milestone:           
     Component:  Unclassified  |   Resolution:           
      Keywords:                |    Sensitive:  0        
Estimatedhours:  0.0           |        Hours:  0        
      Billable:  1             |   Totalhours:  0        
      Internal:  0             |  
-------------------------------+--------------------------------------------
Changes (by vorner):

  * owner:  vorner => jelte


Comment:

 Replying to [comment:3 jelte]:
 > recursor.cc:113: comment only talks about upstream_, not listen_

 Ah, right. Fixed.

 > do these values really need to be public?

 Yes, because they are accessed directly. Creating setters/getters for
 private implementation class that lives only in one file seems like an
 overkill. Making it private and adding a friend to the only class that
 uses it (Recursor) doesn't really sound reasonably too.

 Actually, what I use in these situations is nested private struct ‒ noone
 from outside can reach it, but the owning class has full access to it. But
 I didn't change it, as it already exists.

 > Regarding that comment at recursor.c:563: If we try to update the
 > interfaces we listen on, and it fails, and we try to revert, and
 > that fails too, we should probably just give up completely.

 Done.

 > We could try to be a bit smarter (figure out if there are
 > addresses in both old and new, try to add new first, and then
 > remove the old ones, is one of them, if the adding failed, at least
 > we'd still be listening on the old ones) but I think giving up is
 > just as reasonable (and this is i guess also dependent on #384).

 Well, I wanted to avoid that. I would have to keep track of what sockets
 are which address, allow removing them selectively and so on. It doesn't
 seem worth the effort when the addresses would be configured only once
 probably and the rollback should work anyway.

 > For now, apart from the minor issues stated at the beginning of this
 comment, I think it this code is good. With the note that once we change
 those key strings as part of #384.

 There are 3 more commits on the branch.

 Do you think this can be merged and notes added to the #384 and #388 of
 what needs to be updated then? Or still some problems?

 Thank you

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