So to clarify, instead of the read-only node which is limited to handling disaster recovery tasks only, you can now start a secondary node which can handle both: disaster recovery and VCS polling activity as well. In the future versions we’ll change the running builds node to this approach too. So the secondary node will be able to handle VCS polling and/or data from agents. And what is handled and where will be configured by the administrator on the main server.
Why we’ve chosen VCS polling? Because as it turns out it can be quite resource consuming, both in terms of CPU and memory. The main contributors to the CPU usage are:
discovering of VCS root instances, which involves traversing all active configurations and resolving parameter references
SSH / SSL connections (handshakes can be CPU intensive)
calculation of affected build configurations when detected changes are persisted into the database
As to commit hooks, they should be configured for the main server. If you already have them, no changes are needed: once you start a secondary node with the VCS polling responsibility, the enabled commit hooks will continue to function as before.
See documentation on how to configure and start a secondary node.