Opened 9 years ago

Closed 6 years ago

#948 closed defect (wontfix)

old Xfrin/master_addr configuration is in the way

Reported by: jreed Owned by:
Priority: medium Milestone: Remaining BIND10 tickets
Component: configuration Version: bind10-old
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: Core Feature Depending on Ticket:
Estimated Difficulty: 0.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no


This is related to #945.

zone-related info is in xfrin, not zonemgr. master_addr is not directly in xfrin anymore, but one of the values of Xfrin/zones.

If you have old configuration in place, it gets in the way:

> config show Xfrin      
Xfrin/transfers_in      10      integer (default)
Xfrin/zones     []      list    (default)
> config show_json Xfrin
{"master_addr": ""}

I think something should loudly complain.

And now bindctl is showing two different sets of values and doesn't tell me which is real.

jelte says I think we should have per-module config version numbers.

Here is an example of problem:

> config show_json Xfrin
{"master_addr": ""}
> config add Xfrin/zones
> config set Xfrin/zones[0]/name foo
> config set Xfrin/zones[0]/master_addr
> config diff
{'Xfrin': {'zones': [{'name': 'foo', 'master_addr': ''}]}}
> config commit
Error: unknown item master_addr
Configuration not committed
> config show_json Xfrin
{"zones": [{"name": "foo", "master_addr": ""}]}
> config diff
{'Xfrin': {'zones': [{'name': 'foo', 'master_addr': ''}]}}

Looks like "show_json" shows what is not committed yet.

It does complain, only way too late.

Jelte said "afraid the only quick workaround is to stop bind10 and manually remove that original master_addr from b10-config.db".

So that is what I did.

Manually editing the config database is not what we want to do so I am opening ticket.


Change History (6)

comment:1 Changed 9 years ago by shane

  • Milestone changed from New Tasks to Year 3 Task Backlog

comment:2 Changed 9 years ago by jreed

Also see #986.

comment:3 Changed 8 years ago by shane

So we need some sort of generic way to handle converting old configuration to new ones. Do our .spec files have any versioning? That seems useful.

comment:4 Changed 8 years ago by shane

  • Sub-Project changed from DNS to Core

comment:5 Changed 6 years ago by tomek

  • Milestone set to Remaining BIND10 tickets

comment:6 Changed 6 years ago by tomek

  • Resolution set to wontfix
  • Status changed from new to closed
  • Version set to old-bind10

This issue is related to bind10 code that is no longer part of Kea.

If you are interested in BIND10/Bundy framework or its DNS components,
please check

Closing ticket.

Note: See TracTickets for help on using tickets.