Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#719 closed defect (fixed)

configurable stats do nothing

Reported by: jreed Owned by: jelte
Priority: low Milestone: Sprint-20110517
Component: statistics Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 3.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

stats.spec defines items that can be configured and committed using bindctl, but they don't appear to make any change nor are they stored in configuration db.

I was told in jabber that configuration data items should be configurable and that stats should probably use a completely separate category.

Subtickets

Change History (12)

comment:1 Changed 9 years ago by naokikambe

  • Defect Severity set to N/A
  • Owner set to naokikambe
  • Status changed from new to accepted
  • Sub-Project set to DNS

comment:2 Changed 9 years ago by naokikambe

  • Milestone set to New Tasks
  • Owner changed from naokikambe to UnAssigned
  • Status changed from accepted to reviewing

It's ready for reviewing. Please see also the proposed ChangeLog entry, pushed into the new branch for summary of changes.

comment:3 follow-up: Changed 9 years ago by jelte

Hmm, I think this approach is slightly off. It's a step in the right direction, but I would suggest we *do* put the definition of statistics items in the same spec files, but under a different sublevel, e.g.:

{ "module_spec": {
    "module_name": "my_own_module",
    "module_description": "foo",
    "config_data": [ <list of configurable options> ],
    "commands": [ <list of commands> ],
    "statistics": [ <list of collected statistics> ]
  }
}

This requires us to change the specfile parser, but it would be far less complicated for modules to collect statistics (and I suspect that we want more than one module to do so).

I think we should also put the definitions of module-specific statistics in that module, and not in the specification for the stats-daemon; b10-stats should be agnostic about what specific data is collected, so that modules can define their own, so if we do decide to do the above, I'd suggest we move the specification for things like boot time to the boss spec file, and auth query counters to the auth spec file.

Last edited 9 years ago by jelte (previous) (diff)

comment:4 Changed 9 years ago by jelte

  • Owner changed from UnAssigned to naokikambe

comment:5 in reply to: ↑ 3 Changed 9 years ago by naokikambe

  • Owner changed from naokikambe to jelte

Replying to jelte:

Hello, thank you for comment.

I agree with that idea. The statistics item name may not need to be hardcorded for each module. Furthermore, b10-stats and b10-stats-httpd need the item list which is concatenated by each module. It is almost like stats-schema.spec plus the owner name of the statistics item. Config manager may be able to concatenate it and feed it for them.

However that idea seems for me to be a bit beyond the scope of this ticket. The problem here seems to be that stats module has configuration items unchangable via bindctl. Should we close this defect ticket to be invalid? Otherwise should we merge the branch and should we close it to be fixed?

Anyway I think we need to create the next new ticket(s) along with that idea, although I think it is not so small changes for multiple modules.

Regards,

comment:6 Changed 9 years ago by naokikambe

I have three proposed tickets after this ticket. What about these?

ticket1
update cfgmgr to handle the statistics category in spec file of each module
ticket2
update cfgmgr to accept query of all statistics list in each spec file from stats modules
ticket3
move statistics list in stats spec to each spec file, and update stats and stats-httpd to query all statistics list to cfgmgr

comment:7 follow-up: Changed 9 years ago by jelte

  • Owner changed from jelte to naokikambe

Sounds good. Perhaps we can even add an optional fourth; (read-only) access from bindctl as well. But that's a future wishlist thing (let's first get the rest complete :))

Ok as discussed on the call, this ticket can be merged, and the others created.

Jelte

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

  • Owner changed from naokikambe to jelte

Thank you for comments.

Replying to jelte:

Ok as discussed on the call, this ticket can be merged, and the others created.

My merging branch was done.

Sounds good. Perhaps we can even add an optional fourth; (read-only) access from bindctl as well. But that's a future wishlist thing (let's first get the rest complete :))

I will create that three tickets later, but please let me know if I need to create the forth one too. After creating required tickets is done, I will close this ticket.

Regards,

comment:9 Changed 9 years ago by shane

  • Milestone changed from New Tasks to Sprint-20110517

Moving this ticket to the current sprint, as it was done during this time.

comment:10 in reply to: ↑ 8 Changed 9 years ago by naokikambe

Replying to naokikambe:

After creating required tickets is done, I will close this ticket.

I have created new three tickets(#928, #929, #930), but I corrected their titles a little bit. If all of these are ok for you, I will close this ticket. Please let me know.

comment:11 Changed 9 years ago by jelte

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

ok, looks good. The fourth one is not necessary right now (just an idea for a future expansion of bindctl).

I'll take the liberty of closing this ticket myself :)

comment:12 Changed 9 years ago by naokikambe

  • Estimated Difficulty changed from 0.0 to 3
Note: See TracTickets for help on using tickets.