Opened 9 years ago

Closed 9 years ago

#512 closed task (complete)

Update of statistics daemon for HTTP/XML reporting: design

Reported by: naokikambe Owned by: vorner
Priority: medium Milestone: A-Team-Sprint-20110209
Component: statistics Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity:
Sub-Project: Feature Depending on Ticket:
Estimated Difficulty: 5.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

Update document of statistics daemon for HTTP/XML reporting: Stats module

Subtickets

Change History (7)

comment:1 Changed 9 years ago by naokikambe

  • Milestone set to A-Team-Sprint-20110209

add milestone

comment:2 Changed 9 years ago by naokikambe

  • Estimated Difficulty changed from 0.0 to 3.0
  • Owner changed from naokikambe to UnAssigned
  • Status changed from new to reviewing

Updating the wikipage "HTTP/XML interface" is done. It's ready for reviewing.

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

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

  • Owner changed from UnAssigned to naokikambe

I had a look (I'm not sure if I should have, if the statistics team wanted to review it themselfs). The design makes sense by itself, just two notes:

  • Would it be possible to specify the configuration by the config manager instead of the command line options? After all, this way boss needs to know the command line options and it is hard to have full runtime configuration.
  • Is it needed for the daemon to be running all the time? As we talked on the F2F, there's another possibility ‒ havig a cgi script that would start, download the data from stats module, produce the output and terminate (therefore not running and taking memory) and we could have any web server to listen. If it was considered and decided it is not the way to go, then OK.

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

  • Estimated Difficulty changed from 3.0 to 5.0
  • Owner changed from naokikambe to vorner

Hello Michal-san,

Replying to vorner:

I had a look (I'm not sure if I should have, if the statistics team wanted to review it themselfs). The design makes sense by itself, just two notes:

Thank you very much for reviewing and good feedbacks. I think this designing task should be reviewed by non-JPRS members. Since the basis of the design have been already discussed in the last F2f meeting, I think the internal review by JPRS-only members is no longer important much.

  • Would it be possible to specify the configuration by the config manager instead of the command line options? After all, this way boss needs to know the command line options and it is hard to have full runtime configuration.

Yes, I think it can also accept the configuration from the config manager. But the listening address and port number are specified in the command-line option. it is like same one in "Cmdctl" or in "Auth". However I think other configurations can be specified by the config manager. I have updated the wikipage a little according to the thoughts. Please see StatsModule#HTTPXMLinterface again.

  • Is it needed for the daemon to be running all the time? As we talked on the F2F, there's another possibility ‒ havig a cgi script that would start, download the data from stats module, produce the output and terminate (therefore not running and taking memory) and we could have any web server to listen. If it was considered and decided it is not the way to go, then OK.

Yes, it can be running all the time. In this design, it has the web-server implementation but doesn't have CGI scripts. However another possibility, which is having CGI scripts and is depending on a third-party web server like "Apache", is also reasonable for me. If other modules also need a third-party web server in the future, I think the design of "Stats" module may be changed.

comment:5 in reply to: ↑ 4 ; follow-up: Changed 9 years ago by vorner

  • Owner changed from vorner to naokikambe

Good morning

Replying to naokikambe:

  • Would it be possible to specify the configuration by the config manager instead of the command line options? After all, this way boss needs to know the command line options and it is hard to have full runtime configuration.

Yes, I think it can also accept the configuration from the config manager. But the listening address and port number are specified in the command-line option. it is like same one in "Cmdctl" or in "Auth". However I think other configurations can be specified by the config manager. I have updated the wikipage a little according to the thoughts. Please see StatsModule#HTTPXMLinterface again.

Well, the fact that some modules take configuration as command line arguments is due to historical reasons (I guess the modules are older than the config manager itself).

It makes sense to provide command line parameters to override settings. But the need to reconfigure it it runtime is there and we will need to update the other modules to support it. So if you expect that the command lines arguments are short-term solution, then OK.

  • Is it needed for the daemon to be running all the time? As we talked on the F2F, there's another possibility ‒ havig a cgi script that would start, download the data from stats module, produce the output and terminate (therefore not running and taking memory) and we could have any web server to listen. If it was considered and decided it is not the way to go, then OK.

Yes, it can be running all the time. In this design, it has the web-server implementation but doesn't have CGI scripts. However another possibility, which is having CGI scripts and is depending on a third-party web server like "Apache", is also reasonable for me. If other modules also need a third-party web server in the future, I think the design of "Stats" module may be changed.

ACK. I guess that modifying it from stand-alone HTTP server to CGI script would be easy, as most of the logic will be in generating the correct output and it doesn't matter much which it is plugged into.

So, shall we close this as complete?

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

  • Owner changed from naokikambe to vorner

Hello,

Replying to vorner:

Well, the fact that some modules take configuration as command line arguments is due to historical reasons (I guess the modules are older than the config manager itself).

It makes sense to provide command line parameters to override settings. But the need to reconfigure it it runtime is there and we will need to update the other modules to support it. So if you expect that the command lines arguments are short-term solution, then OK.

Sorry, I didn't know the historical reason well. But I'm afraid that the implementation would become a little more complex if we make the both ways of configuration effective. So we would leave this design to be a short-term solution as you mentioned.

ACK. I guess that modifying it from stand-alone HTTP server to CGI script would be easy, as most of the logic will be in generating the correct output and it doesn't matter much which it is plugged into.

That's right. But I cannot decide whether we should bundle a stand-alone HTTP server in the BIND 10 package or not. If we don't bundle it, we would need the user's configurations of an already running HTTP server. So we would discuss it as another topic later.

So, shall we close this as complete?

OK. I'm closing it unless you have more comments or questions.

Thanks,

comment:7 Changed 9 years ago by vorner

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

Ok, let's close it (I'm closing it directly to save a roundtrip).

Note: See TracTickets for help on using tickets.