Opened 6 years ago

Closed 6 years ago

#1890 closed defect (fixed)

CFGMGR_RENAMED_CONFIG_FILE misleading

Reported by: jreed Owned by: muks
Priority: medium Milestone: Sprint-20120612
Component: ~Boss of BIND (obsolete) Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: Low
Sub-Project: Core Feature Depending on Ticket:
Estimated Difficulty: 2 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

2012-04-12 22:26:28.642 INFO  [b10-cfgmgr.cfgmgr] CFGMGR_RENAMED_CONFIG_FILE renamed configuration file /export/home/users/jreed/builder/work/BIND10/20120412030902-Solaris10-sparc-GCC/install/var/bind10-devel/b10-config.db to /export/home/users/jreed/builder/work/BIND10/20120412030902-Solaris10-sparc-GCC/install/var/bind10-devel/b10-config.db.bak, will create new /export/home/users/jreed/builder/work/BIND10/20120412030902-Solaris10-sparc-GCC/install/var/bind10-devel/b10-config.db

Maybe the message should not say ", will create new %1". (It does not exist until something later creates it.)

And it didn't really rename it. Maybe just say that the clear-config happened: The %1 configuration was removed, a backup was placed at %2.

Also this should not be a INFO, but should be more noticeable like a WARN.

Subtickets

Change History (10)

comment:1 Changed 6 years ago by shane

  • Defect Severity changed from N/A to Low
  • Milestone changed from New Tasks to Next-Sprint-Proposed

It should be a WARN if it happens by the system itself, I think (in response to a bogus config, for example), otherwise INFO seems fine to me.

I agree we can clear up the message though!

comment:2 Changed 6 years ago by jelte

  • Milestone changed from Next-Sprint-Proposed to Sprint-20120529

comment:3 in reply to: ↑ description Changed 6 years ago by muks

  • Owner set to muks
  • Status changed from new to assigned

Picking. I'm fairly sure the file is renamed if I remember jelte's branch correctly.. anyway will check.

comment:4 in reply to: ↑ description Changed 6 years ago by muks

  • Owner changed from muks to jreed
  • Status changed from assigned to reviewing

Hi Jeremy

Replying to jreed:

Maybe the message should not say ", will create new %1". (It does not exist until something later creates it.)

This message seems to be correct. It exactly says what it does. Do you want it to say "..., will create new %1 when necessary." ? It can be added to clarify what happens.

And it didn't really rename it. Maybe just say that the clear-config happened: The %1 configuration was removed, a backup was placed at %2.

If it didn't, that would be a bug. In #1443, Jelte did add testcases that verifed that the file had been moved correctly. It should rename the file printed in the log message to the .bak backup.

Do you intend to say that a new file with the name is created, so it does not appear as a rename? Even in this case, the log message seems fine as it says a new file will be created in its place.

Also this should not be a INFO, but should be more noticeable like a WARN.

WARN is for warning the user about problems or potential problems, whereas the config file is renamed due to a switch invoked by the user. INFO is fine for this I think.

comment:5 follow-up: Changed 6 years ago by jreed

It makes the admin think that the configuration was renamed and that they should consider using the new name.

The "will create" make admin think it may happen then or soon, but really it will never happen until something tells it to create a new configuration.

I think some may choose to not log INFO. WARNING may be useful for other admins to know this happened.

(In other words, my thoughts never changed on why I opened the ticket.)

comment:6 in reply to: ↑ 5 Changed 6 years ago by muks

Replying to jreed:

It makes the admin think that the configuration was renamed and that they should consider using the new name.

Now I follow what you meant in the description :)

The "will create" make admin think it may happen then or soon, but really it will never happen until something tells it to create a new configuration.

I think some may choose to not log INFO. WARNING may be useful for other admins to know this happened.

The clear-config action currently only happens if it is requested by an admin. I agree it should be logged visibly if it happens automatically, but WARNING is something that should be to warn the admin (of impending error/failure situations), not as a notice. The closest level we have right now for this message is INFO.

Maybe we can introduce a NOTICE level for such messages. Let's talk about it in the bi-weekly call.

(In other words, my thoughts never changed on why I opened the ticket.)

comment:7 Changed 6 years ago by muks

  • Owner changed from jreed to UnAssigned

The message id, blurb and description were changed. Up for review.

comment:8 Changed 6 years ago by jelte

  • Owner changed from UnAssigned to jelte

comment:9 Changed 6 years ago by jelte

  • Owner changed from jelte to muks

This seems fine to me, please go ahead

comment:10 Changed 6 years ago by muks

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

Merged to master:

* e8cabc6 [1890] Clarify message shown when command to clear the config file is used

Resolving as fixed. Thank you for the review.

Note: See TracTickets for help on using tickets.