Opened 9 years ago

Closed 8 years ago

#916 closed task (fixed)

implement a prototype for stats snmp interface

Reported by: naokikambe Owned by: naokikambe
Priority: medium Milestone: Sprint-20111220
Component: statistics Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket: SNMP stats
Estimated Difficulty: 10 Add Hours to Ticket: 0
Total Hours: 30.00 Internal?: no

Description (last modified by naokikambe)

The goal of this ticket is to investigate snmp library and to implement a prototype. This is an investigation task before design task for stats snmp interface.

Subtickets

Change History (13)

comment:1 Changed 9 years ago by naokikambe

  • Description modified (diff)
  • Status changed from new to accepted

comment:2 Changed 9 years ago by shane

  • Milestone changed from New Tasks to Year 3 Task Backlog
  • Owner changed from naokikambe to UnAssigned
  • Status changed from accepted to assigned

I'm moving this to the Year 3 backlog. I am also making it UnAssigned?, since I don't think it is being actively worked on yet.

comment:3 Changed 8 years ago by naokikambe

  • Milestone changed from Year 3 Task Backlog to Next-Sprint-Proposed

comment:4 Changed 8 years ago by jelte

  • Estimated Difficulty changed from 0.0 to 10

comment:5 Changed 8 years ago by naokikambe

  • Status changed from assigned to reviewing

It's ready for reviewing.

The branch doesn't need to be really merged with the master because this code is prototype which is used for documenting the basic design in #1448.

comment:6 Changed 8 years ago by jinmei

  • Milestone changed from Year 3 Task Backlog to Next-Sprint-Proposed

comment:7 Changed 8 years ago by jelte

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

comment:8 Changed 8 years ago by shane

  • Feature Depending on Ticket set to SNMP stats

comment:9 Changed 8 years ago by vorner

  • Owner changed from UnAssigned to vorner

comment:10 Changed 8 years ago by vorner

  • Owner changed from vorner to naokikambe

Hello

As this is only prototype code, I didn't take a close look to stuff like programming and style practices and mostly ignored the tests in the review as well.

I've noticed some slight things, that may be just because this is simple experimental version:

  • It seems the list of items (or whatever it is called) is generated from spec files manually rather than dynamically on the fly. As the daemons might come and go and nothing really makes them say where their spec file is (provided it is in a file at all), this doesn't seem correct.
  • When a request is made, it downloads the whole set of statistics over message bus and then picks the single one it needed. Shouldn't it ak only for the needed data?
  • While the http stats daemon servers its own http daemon, this one seems to be used from inside some other external tool. It is slightly inconsistent, but I don't think it should pose some other kind of problem.

Or, was this the purpose of the review? I'm not sure, if you don't want to merge to master, it feels slightly unusual.

Thanks

comment:11 follow-up: Changed 8 years ago by naokikambe

  • Owner changed from naokikambe to vorner

Replying to vorner:
Sorry for my late response.

As this is only prototype code, I didn't take a close look to stuff like programming and style practices and mostly ignored the tests in the review as well.

Thank you! That's no problem. The result of this task is just an assistance
for the next documentation #1448.

I've noticed some slight things, that may be just because this is simple experimental version:

  • It seems the list of items (or whatever it is called) is generated from spec files manually rather than dynamically on the fly. As the daemons might come and go and nothing really makes them say where their spec file is (provided it is in a file at all), this doesn't seem correct.

Do you mention about gen-mibfile.py? That is loaded only when
bind10 is compiled. Anyway in such circumstances as the SNMP feature
is used, we don't imagine that the list of statistics items can be
changed unexpectedly by the user hands, whenever bind10 codes are
being complied or the bind10 daemons are running. However, this might
be incorrect but I cannot imagine the better way. Because SNMP doesn't
provide the way to change the list dynamically.

  • When a request is made, it downloads the whole set of statistics over message bus and then picks the single one it needed. Shouldn't it ak only for the needed data?

It isn't OK. That is a bug on the prototype. I will fix it in the
implementation phase. I've added the TODO tag at git e94a7a6e1c. Could
you see that?

  • While the http stats daemon servers its own http daemon, this one seems to be used from inside some other external tool. It is slightly inconsistent, but I don't think it should pose some other kind of problem.

That's good point. In order to keep consistency with the HTTP stats
daemon, I think such SNMP daemon should be independent too. But SNMP
is technically so complicated that the implementation including the
deamonlization cannot be completed within the Y3 plan. Otherwise a
library for SNMP like http.server might be useful if there is. OTOH,
most of the system administrators may want the bind10 daemon to
coexist with the SNMP daemon like net-snmp for monitoring
availabilities of the whole system. Then the situation might be more
complicated. That's the reason why I choose the pass_persis directive
in snmpd.conf for the convenience. I think the new trial to daemonlize
should be put in the scope of Y4 or later.

Or, was this the purpose of the review? I'm not sure, if you don't want to merge to master, it feels slightly unusual.

Sorry for the confusion. I don't think that branch should be merged
with the master. But the codes in the branch are very useful for the
implementation phase which will come after the documentation phase
#1448, I won't delete that branch.

Thanks,

Last edited 8 years ago by naokikambe (previous) (diff)

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

  • Owner changed from vorner to naokikambe
  • Total Hours changed from 0 to 0.75

Hello

Replying to naokikambe:

I've noticed some slight things, that may be just because this is simple experimental version:

  • It seems the list of items (or whatever it is called) is generated from spec files manually rather than dynamically on the fly. As the daemons might come and go and nothing really makes them say where their spec file is (provided it is in a file at all), this doesn't seem correct.

Do you mention about gen-mibfile.py? That is loaded only when
bind10 is compiled. Anyway in such circumstances as the SNMP feature
is used, we don't imagine that the list of statistics items can be
changed unexpectedly by the user hands, whenever bind10 codes are
being complied or the bind10 daemons are running. However, this might
be incorrect but I cannot imagine the better way. Because SNMP doesn't
provide the way to change the list dynamically.

Yes, mostly because the gen-mibfile.py and generally the thing that because it looks like the list of statistics is considered static in more or less dynamic bind10, which feels strange.

I guess SNMP doesn't support a way to push the change of list actively. But it must be able to answer a query „give me list of variables“ and the answer could be different for future queries.

What I fear is, user will start up for the first time, it will create some statistic list for him, then disables auth and enables resolver. Provided the first list was correct, it now must be wrong. So it would make sense to me to delay the creation of the list for the time the list of variables is requested.

But that might be just my preference. Maybe the problem I see wouldn't be issue in real life anyway.

  • While the http stats daemon servers its own http daemon, this one seems to be used from inside some other external tool. It is slightly inconsistent, but I don't think it should pose some other kind of problem.

That's good point. In order to keep consistency with the HTTP stats
daemon, I think such SNMP daemon should be independent too. But SNMP
is technically so complicated that the implementation including the
deamonlization cannot be completed within the Y3 plan. Otherwise a
library for SNMP like http.server might be useful if there is. OTOH,
most of the system administrators may want the bind10 daemon to
coexist with the SNMP daemon like net-snmp for monitoring
availabilities of the whole system. Then the situation might be more
complicated. That's the reason why I choose the pass_persis directive
in snmpd.conf for the convenience. I think the new trial to daemonlize
should be put in the scope of Y4 or later.

I see.

Or, was this the purpose of the review? I'm not sure, if you don't want to merge to master, it feels slightly unusual.

Sorry for the confusion. I don't think that branch should be merged
with the master. But the codes in the branch are very useful for the
implementation phase which will come after the documentation phase
#1448, I won't delete that branch.

So, then, you probably can close this ticket whenever you feel like it, I guess, and keep the branch around. Maybe the branch could be renamed to some experiments/something so it is not deleted on some cleanup?

With regards

comment:13 in reply to: ↑ 12 Changed 8 years ago by naokikambe

  • Resolution set to fixed
  • Status changed from reviewing to closed
  • Total Hours changed from 0.75 to 30.00

Hello

Replying to vorner:

Yes, mostly because the gen-mibfile.py and generally the thing that because it looks like the list of statistics is considered static in more or less dynamic bind10, which feels strange.

I guess SNMP doesn't support a way to push the change of list actively. But it must be able to answer a query „give me list of variables“ and the answer could be different for future queries.

What I fear is, user will start up for the first time, it will create some statistic list for him, then disables auth and enables resolver. Provided the first list was correct, it now must be wrong. So it would make sense to me to delay the creation of the list for the time the list of variables is requested.

But that might be just my preference. Maybe the problem I see wouldn't be issue in real life anyway.

Yes, we might need to consider the creation timing of the MIB file.
The names in MIB can be duplicated in real life as you mentioned
above. That might be issue. We should consider about naming the
statistics item in both the spec file and the MIB file. Anyway, the
MIB file might be installed by user hands into another SNMP client
which we never know. We cannot control such situation. We might need
to keep the tool gen-mibfile.py somewhere for the MIB recreation.

So, then, you probably can close this ticket whenever you feel like it, I guess, and keep the branch around. Maybe the branch could be renamed to some experiments/something so it is not deleted on some cleanup?

Thank you for suggestion. I've locally merged that with the master and
pushed to the remote experimental branch, and then I've
deleted the existent branch. So I'm closing the ticket.

Best

Note: See TracTickets for help on using tickets.