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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 karsten):

 We should probably first come to a conclusion how the configuration reload
 is triggered.  I tried to come up with a few examples how other services
 handle configuration changes:

  - Apache lets you edit config files and won't bother looking at them
 until you `service apache2 reload`.  I find that pretty easy to work with.
  - Tomcat checks every few seconds if there are new or updated webapps in
 its webapps folder and auto-deploys them.  I'm not a big fan of that
 approach because of the random (though short) delay, but I got used to it.
  - `visudo` lets you edit the sudoers file and makes changes effective
 immediately upon saving.  I'm okay with that, but I don't like how this is
 bound to a specific editor (which you can change, but which still seems
 cumbersome).
  - `crontab -e` lets you update the crontab and makes changes effective
 immediately.  I'm always very careful and afraid of making mistakes when
 making changes, which I wouldn't be if there was a separate reload step
 and I'd have the chance to review the configuration before reloading.

 So, generalizing from these examples:
  - I prefer using the editor of my choice, without having to look up how
 to define that editor somewhere, but just by opening the config file,
 editing, and saving.
  - I prefer that changes become effective immediately when I trigger the
 update, not at a random time after the change.
  - I prefer being able to review configuration changes, for example by
 copying the original file before editing and comparing the copy to the
 updated file after saving.

 However, those are only my preferences.  I'd like us to find a solution
 that's least surprising to current and future operators.  I wonder if we
 should prepare an operator's manual with different options (not only for
 making configuration changes but also for configuring logging and other
 things unrelated to this ticket) and give that to potential operators to
 hear what they'd find most usable and least surprising.  Hmm.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19720#comment:14>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs