Opened 9 years ago

Closed 9 years ago

#202 closed defect (fixed)

cfgmgr and bindctl and unknown configurations

Reported by: jreed Owned by: jelte
Priority: medium Milestone:
Component: Unclassified Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity:
Sub-Project: Feature Depending on Ticket:
Estimated Difficulty: 0.0 Add Hours to Ticket:
Total Hours: Internal?: no

Description

$ /home/reed/opt/bind10/bin/bindctl  
["login success "] login as root
> config set foo jeremy
> config diff
{'foo': 'jeremy'}
> config commit

hangs there

Noticed one minor difference with trac183 -- when I tried to open bindctl again, it wouldn't give me a prompt (since backend is hanging I guess).

Subtickets

Change History (12)

comment:1 Changed 9 years ago by zhanglikun

  • billable set to 0
  • Estimated Difficulty set to 0.0
  • Internal? unset
  • Owner set to jreed
  • Status changed from new to reviewing

Tested it just now, can't reproduce it now, should close it?

comment:2 Changed 9 years ago by jreed

  • Owner changed from jreed to UnAssigned

No longer locking for me.
but still accepts and "commit" won't complain about unknown configurations. So if someone makes a typo they may think they configuration was stored, but it is not.

comment:3 Changed 9 years ago by shane

  • Owner changed from UnAssigned to shane
  • Status changed from reviewing to accepted

comment:4 Changed 9 years ago by shane

  • Owner changed from shane to UnAssigned
  • Status changed from accepted to assigned

comment:5 Changed 9 years ago by jelte

  • Owner changed from UnAssigned to jelte
  • Status changed from assigned to accepted

should we fail immediately? (i.e. upon 'set'),

comment:6 Changed 9 years ago by jelte

(oops hadn't intended to add that partly formed question yet)

should we fail immediately? (i.e. upon 'set'), on 'commit', or both?

comment:7 Changed 9 years ago by jelte

The first case was quite easy; bindctl now immediately errors if one uses config set with an identifier that is not in a known module or if said identifier does not point to something that is specified in that module's .spec file.

This does mean however that as of now we cannot change values of modules that are not running (this may need to be added to the offline-config task as a separate issue to consider)

comment:8 Changed 9 years ago by jelte

bindctl-side changes in r3757

comment:9 Changed 9 years ago by jelte

  • Owner changed from jelte to UnAssigned
  • Status changed from accepted to reviewing

r3765 has more extensive changes; the validation logic now also checks if there is data in there that is not in the specification in the spec file.

but due to r3757, these should not be user-visible; in principle, at least with bindctl, this should not occur, but of course it's very useful for general data integrity.

proposed changelog entry:
[func or bug?]
bindctl (and the configuration manager in general) now no longer accepts 'unknown' data; i.e. data for modules that it does not know about, or configuration items that are not specified in the .spec files.

comment:10 Changed 9 years ago by zhanglikun

I have reviewed, please merge. I would like the entry to be "bug".

comment:11 Changed 9 years ago by zhanglikun

  • Owner changed from UnAssigned to jelte

comment:12 Changed 9 years ago by jelte

  • Resolution set to fixed
  • Status changed from reviewing to closed

Merged. Closing ticket.

Note: See TracTickets for help on using tickets.