[tor-bugs] #19720 [Metrics/CollecTor]: CollecTor should be re-configurable without restart

[Tor Bug Tracker & Wiki]

#19720: CollecTor should be re-configurable without restart
-------------------------------+---------------------------------
 Reporter:  iwakeh             |          Owner:  iwakeh
     Type:  enhancement        |         Status:  needs_review
 Priority:  High               |      Milestone:  CollecTor 1.0.0
Component:  Metrics/CollecTor  |        Version:
 Severity:  Normal             |     Resolution:
 Keywords:  ctip               |  Actual Points:
Parent ID:                     |         Points:
 Reviewer:                     |        Sponsor:
-------------------------------+---------------------------------

Comment (by iwakeh):

 Replying to [comment:10 karsten]:
 > The impatient?  Nooo, not true.  The forgetful and easily confused!

 :-)

 >
 > Okay, one question and two suggestions:
 >  - What happens if the operator breaks the configuration file?  Will
 current module runs be affected, that is, will they be aborted together
 with the scheduler?  If not, will the scheduler make another attempt to
 re-read the configuration file 60 (or 5) seconds later?  And if so, will
 it warn every 60 (or 5) seconds that the configuration is broken?  Okay,
 that's more than one question, but these seem related.

 The design should be quite robust concerning editing errors.
 First, there are actually two categories of 'breaking' the configuration:
 1. syntactically: the properties syntax is wrong and the file cannot be
 read by `java.util.Properties`
 2. semantically: a valid property contains a bad value, e.g. a valid but
 wrong URL.

 Case 1: an
 [https://gitweb.torproject.org/user/iwakeh/collector.git/tree/src/main/java/org/torproject/collector/conf/Configuration.java?h=task-19720
 -reread-configuration&id=abedf087def7f66b3446f5b019cff5ff2202f9f0#n74
 error is logged] and the modules keep running with their working
 configuration, i.e. the modules don't hear about a new config.

 Case 2: All modules are informed and will use the new configuration with
 their next run. Depending on the 'wrongness' of the value supplied the
 module affected will in worst case throw an Exception. All modules with
 correct properties keep running fine.  The affected module will be
 rescheduled at the scheduled time from the start-up configuration.

 In both cases `Configuration` keeps checking the modified-time, no matter
 what the edit caused, but it won't re-read unless there was another
 change.  (Looking at the code after working on #19771 I'm going to change
 the
 [https://gitweb.torproject.org/user/iwakeh/collector.git/tree/src/main/java/org/torproject/collector/conf/Configuration.java?h=task-19720
 -reread-configuration&id=abedf087def7f66b3446f5b019cff5ff2202f9f0#n73
 catch clause] into catch-all, too.)

 >  - 10 or 15 seconds might work, too, if 5 is too small.  Just enough to
 save the file and `tail -f` the log file to see how the changes are
 processed.  So, I'd say anything between 5 and 15 would work, please pick
 your favorite.

 Fine.

 >  - The behavior of all this should be described at the top of
 `collector.properties`, so that operators know exactly what will happen
 when they edit the file while CollecTor is running rather than having to
 learn it from the logs after it has happened.

 This is a very important point!

 >
 > Sorry to make this more difficult, but I'm thinking of all the services
 I'm running and how to memorize how to do that, and I'm thinking of
 external folks running our services in the near future and making this as
 easy as possible for them.  Thanks!

 In the opposite, voicing all the questions and doubts is important!
 It surely takes less time to write about things beforehand than
 troubleshooting an externally running instance later and preparing bugfix-
 releases.

 Thanks!

 Are there any more questions/suggestions? Can I start with the proposed
 changes?

--
Ticket URL: <https://troodi.torproject.org/projects/tor/ticket/19720#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online