#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 _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs