BIND 10 #1491: Boss/components config option got set to empty
BIND 10 Development
do-not-reply at isc.org
Wed Apr 11 09:11:11 UTC 2012
#1491: Boss/components config option got set to empty
-------------------------------------+-------------------------------------
Reporter: jelte | Owner: UnAssigned
Type: | Status: reviewing
defect | Milestone:
Priority: | Sprint-20120417
medium | Resolution:
Component: | Sensitive: 0
Unclassified | Sub-Project: DNS
Keywords: | Estimated Difficulty: 6
Defect Severity: | Total Hours: 0
Medium |
Feature Depending on Ticket: |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Changes (by jelte):
* owner: jelte => UnAssigned
Comment:
So what happens is, bindctl keeps 'local' data, which is really just the
changes from the 'current' data as present in cfgmgr. For most basic
types, changing a value just means giving it a value in local data, and
when it is committed it is overwritten (after validation etc.). But we
don't really have a representation of 'changes'; so for lists and sets, if
we add or remove an element, we need to copy the entire list or set to
'local data', then remove or add the element (since we have no
representation of difference, the entire list or set will be overwritten
when it is committed).
This was already implemented, but we missed at least one scenario; if a
child element of a named set is modified, the local data only stores that
specific element of the set (it is copied if you add or remove an element
in a named_set directly).
You can reproduce the problem like this; (warning; this will result in all
modules being removed, including b10-cmdctl)
Doing config show Boss/components between each step may show more info on
what happens; the error after the first commit is unrelated (but
boss/components is our only use of named_set afaik)
{{{
bindctl
> config set Boss/components/b10-stats kind needed
> config commit
Error: Changing configuration of a running component is not yet supported.
Remove and re-add b10-stats to get the same effect
Configuration not committed
> config remove Boss/components b10-stats
> config commit
> config show Boss
Failed to send request, the connection is closed
}}}
(then retry this in the branch)
So when the first set is done, the 'new named set' contains only
b10-stats, as it is not directly changed itself, and is not copied to
'local'. Of course in this specific example the commit fails, and you do
'config remove' on b10-stats, to re-add it later. But after the remove the
set is empty. If you commit it then, boss will stop all configurable
modules...
The immediate solution is to copy named_sets to local data completely if
any part of it is changed. The real solution is in the api; we need to
have a way to communicate 'differences' for specific types (additions and
deletions, for lists and maps, and 'something has changed in a child, but
leave the rest alone', etc.). I have no doubt that there are more issues
like this (but this one is the most dangerous one I know of and wanted
fixed right now, as you can lock yourself out of the system by accident)
--
Ticket URL: <http://bind10.isc.org/ticket/1491#comment:12>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list