Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#2180 closed defect (fixed)

Warn administrator when creating an empty SQLite data source

Reported by: shane Owned by: vorner
Priority: medium Milestone: Sprint-20120904
Component: Unclassified Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: Medium
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 4 Add Hours to Ticket: 0
Total Hours: 1.35 Internal?: no

Description

We should warn administrators when we create an empty SQLite data source. (I was caught by this when using an incorrect path on my system.)

Subtickets

Change History (12)

comment:1 Changed 7 years ago by jelte

  • Milestone changed from New Tasks to Sprint-20120821

comment:2 Changed 7 years ago by jinmei

I'm afraid this ticket is not very clear about exactly what's the
problem and (therefore) how we address that.

I suggest we *not* carry it over to the next sprint, passing it to
the requester (Shane) for further clarification.

comment:3 Changed 7 years ago by vorner

  • Owner set to vorner
  • Status changed from new to accepted

comment:4 Changed 7 years ago by vorner

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

Hello

This one should be simple. I don't think it needs a changelog entry, it's tiny.

comment:5 Changed 7 years ago by jinmei

  • Owner changed from UnAssigned to jinmei

comment:6 follow-up: Changed 7 years ago by jinmei

I've made one small editorial change.

Personally, I'd like to keep the log level INFO; I don't like to use a
higher level of logs (especially warn and error) unless the event
should generally be considered abnormal. Since INFO is the default
log level, this event will still be logged by default, and, my
understanding of our discussion of this ticket, the important part is
to include the path to the DB file in the log so that such stupid^w
poor administrators will easily notice what's wrong when something is
wrong, rather than by raising the log level.

Another point: I'd rather just remove DATASRC_SQLITE_SETUP_OLD_API
than revising it as a separate message ID, because we'll soon remove
the .cc anyway, and then this new ID will be dangling.

comment:7 Changed 7 years ago by jinmei

  • Owner changed from jinmei to vorner

comment:8 in reply to: ↑ 6 ; follow-up: Changed 7 years ago by vorner

  • Owner changed from vorner to jinmei

Hello

Replying to jinmei:

I've made one small editorial change.

Did you push it? I can't find it.

Personally, I'd like to keep the log level INFO; I don't like to use a
higher level of logs (especially warn and error) unless the event
should generally be considered abnormal. Since INFO is the default
log level, this event will still be logged by default, and, my
understanding of our discussion of this ticket, the important part is
to include the path to the DB file in the log so that such stupid^w
poor administrators will easily notice what's wrong when something is
wrong, rather than by raising the log level.

Actually, I believe the original purpose of the ticket was to raise the log level and the path is just a nice extra. It was based on real experience, it took Shane a long time to find the message in the logs, since there are many INFO messages.

And I actually believe WARN is justified here. Creating a new database file is really abnormal situation, you don't do that during the normal operation. You do it once on the first startup and that it is.

Another point: I'd rather just remove DATASRC_SQLITE_SETUP_OLD_API
than revising it as a separate message ID, because we'll soon remove
the .cc anyway, and then this new ID will be dangling.

Well, there'll be many dangling message IDs we'll need to find after that. One more or less is not much of a problem. And I don't like to keep the code in some degrading state just because we plan to remove it Really Soon Now (which, I think, we plan to do for like around a year).

With regards.

comment:9 in reply to: ↑ 8 Changed 7 years ago by jinmei

Replying to vorner:

Okay. I do not necessarily agree with all points, but I won't
strongly oppose to them either. Please feel free to merge.

Replying to jinmei:

I've made one small editorial change.

Did you push it? I can't find it.

Personally, I'd like to keep the log level INFO; I don't like to use a
higher level of logs (especially warn and error) unless the event
should generally be considered abnormal. Since INFO is the default
log level, this event will still be logged by default, and, my
understanding of our discussion of this ticket, the important part is
to include the path to the DB file in the log so that such stupid^w
poor administrators will easily notice what's wrong when something is
wrong, rather than by raising the log level.

Actually, I believe the original purpose of the ticket was to raise the log level and the path is just a nice extra. It was based on real experience, it took Shane a long time to find the message in the logs, since there are many INFO messages.

And I actually believe WARN is justified here. Creating a new database file is really abnormal situation, you don't do that during the normal operation. You do it once on the first startup and that it is.

Another point: I'd rather just remove DATASRC_SQLITE_SETUP_OLD_API
than revising it as a separate message ID, because we'll soon remove
the .cc anyway, and then this new ID will be dangling.

Well, there'll be many dangling message IDs we'll need to find after that. One more or less is not much of a problem. And I don't like to keep the code in some degrading state just because we plan to remove it Really Soon Now (which, I think, we plan to do for like around a year).

With regards.

comment:10 Changed 7 years ago by jinmei

  • Owner changed from jinmei to vorner

comment:11 Changed 7 years ago by vorner

  • Resolution set to fixed
  • Status changed from reviewing to closed
  • Total Hours changed from 0 to 1.35

Thank you, closing

comment:12 Changed 7 years ago by jreed

syslog provides:

LOG_NOTICE Conditions that are not error conditions, but should possibly be handled specially.

INFO may be too busy and may be ignored or specifically excluded.

Now I see we already talked about this in detail (for ticket #1890): http://bind10.isc.org/wiki/WeeklyMinutes20120605 but I don't think we ever made the wikipage about the controversial log messages

Note: See TracTickets for help on using tickets.