[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):

 I would like to separate concerns:

 First of all we provide a product that should work, be easy to deploy, and
 maintainable.
 The deployment part is already pretty easy now: one executable jar and one
 config file.
 Similarly maintenance, which includes troubleshooting of remote instances.
 For helping
 an external operator we simply need: their collector.properties, the
 revision number of the jar, and some log files.

 How operation is actually managed is not our concern.  We should strive to
 make
 many things possible. With the setup we chose so far that's the case.

 Actually all the three nice-to-haves you mention are already possible:

 > 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.

 That's clearly met.

 >  - I prefer that changes become effective immediately when I trigger the
 update, not at a random time after the change.

 I admit the meaning of immediate is stretchable. At the latest five
 seconds after saving the change will be acknowledged by CollecTor; and it
 also informs about when the active modules will use the new config.

 >  - 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.
 >

 That is an operational question, which doesn't affect the product design.
 By adding collector.properties to a git repo you have what you require.
 Ensuring that the changes
 are committed is part of the operation.

 Of course, there are more operational issues: who may alter the
 configuration and the like.
 These are not part of the application/product.

 Saying that some issues are part of operation doesn't mean they're
 unimportant.
 I think they will be important at a later stage when we want to provide a
 Debian
 package of CollecTor, for example.  Then we need to think about how the
 re-configuration
 mechanism has to be wrapped, where to put the configuration, etc.

 The way it is now, leaves lots of room to accommodate many operational
 styles, I think.

 So, I really would like to include the re-config into the first release.
 And, then we improve things.  For a first release it's fine.

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