BIND 10 #225: b10-auth fails if ran from source tree

[BIND 10 Development]

#225: b10-auth fails if ran from source tree
----------------------+-----------------------------------------------------
 Reporter:  jreed     |        Owner:  jelte                                         
     Type:  defect    |       Status:  reviewing                                     
 Priority:  major     |    Milestone:  05. 3rd Incremental Release: Serious Secondary
Component:  b10-auth  |   Resolution:                                                
 Keywords:            |    Sensitive:  0                                             
----------------------+-----------------------------------------------------

Comment(by jinmei):

 Replying to [comment:8 jelte]:

 Responding to non trivial points only.  Others are okay.

 > >  - Please add tests for xfrin
 >
 > Any idea on how? The tests use a test-specific database file, so I think
 this is more integration-testing than unit testing. Something with
 cucumber perhaps?

 When I first saw the patch, I thought we could take a similar approach as
 xfrout_test, that is, defining a mock CCSession class for testing and
 letting it respond to get_remote_config_value().

 But this may lead to a relatively larger refactoring.  If so, I'm okay
 with deferring this to a separate ticket as long as it's addressed soon.

 > >  - !UnixSockServer.get_db_file() do we really need to acquire a lock
 here?  with your change it seems to eliminate the possibility of race.
 besides, since get_remote_config_value() can be time consuming (right?),
 this can be a giant lock.
 >
 > Actually it doesn't take much time, 'remote config' follows a push-
 mechanism, so the pain is there on config changes, not on config access,
 and this is simply a dict lookup. You're right right about not needing a
 lock here, but now that you mention it, we might need them in ccsession
 itself...

 Ah...okay, I see the problem, I think.

 Inter module mutex will lead to a nightmare, we should avoid that.

 I guess a better solution is to have the main thread manage both the
 remote and local config, and worker threads always refer to copies
 closed in the xfrout module.  Do do this, we could do, e.g.
  - add a hook to ModuleCCSession so that the calling module of
    check_command() can get a callback when a remote module is updated,
    or
  - make a communication channel (named pipe or something) between the
    main thread and its children, and pass any dynamic config
    parameters via that channel.  This is expensive, but I suspect
    we'll need this type of channel anyway for faster shutdown (I guess
    the same problem I pointed out for xfrin exists), or
  - let the worker threads subscribe to the channel of the remote
    module (but in that case we may rather think about using separate
    processes than threads)

 Anyway, this race condition is currently a hypothetical issue (python
 cannot run multiple threads on multiple processors/cores if I understand
 it correctly), and solutions won't be easy.  So I think we can leave it to
 a separate ticket (maybe a backlog item).  For now, it should be okay just
 to leave a comment about this problem.

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