BIND 10 #922: Callback for foreign module configuration
BIND 10 Development
do-not-reply at isc.org
Mon May 16 16:10:38 UTC 2011
#922: Callback for foreign module configuration
-------------------------------------+-------------------------------------
Reporter: | Owner: vorner
vorner | Status: reviewing
Type: task | Milestone:
Priority: major | Sprint-20110517
Component: | Resolution:
configuration | Sensitive: 0
Keywords: | Sub-Project: Core
Defect Severity: N/A | Estimated Difficulty: 0.0
Feature Depending on Ticket: | Total Hours: 0
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by jelte):
* owner: jelte => vorner
Comment:
A few comments for now, and I have a few i want documented somewhere so as
not to forget.
Think this was already a problem, but easy to remedy now; we should move
the subscribe() call down until after the last possible exception (or
unsubscribe() before we throw) in the add_remote() call, so that we don't
end up with 'loose' subscription if something goes wrong in the setup.
Do we have/want a strict requirement that module names don't contain dots?
They can't contain / due to another implementation limitation right now.
If we do not have or want such a requirement, perhaps we should have two
separate methods for adding them either with a module name or a file name.
(Also, not necessarily a problem, but we should be aware of it: using a
module name instead of a specfile means that said module has to be running
(so that it is known for config manager) right now. Hopefully we can make
this problem disappear soonish :)))
Can you add a bit of text to the documentation that the handler should
never throw? (or, alternatively, catch any exception when calling it, so
that update and init do not bail out should the handler throw an
exception)
And a few general comments that we should probably create tickets for:
There is a separate python implementation for ccsession etc. we should add
this callback functionality there too (can be a separate ticket so as not
to block the other tickets that depend on this one).
This was already a potential problem, and solving it will probably require
some internal protocol change, but if an updated configuration is rejected
by a module, I don't think the modules that are peeking in on its config
values are notified of this. Same as for previous point, as this was
already a problem, we should probably make this a ticket.
--
Ticket URL: <http://bind10.isc.org/ticket/922#comment:3>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list