amv
commented
10 years ago Now that I think of this, I think there is only one place of the configuration that should be changed often and that is the current pool version. I am contemplating if it would be better to scrap this feature completely and just create a separate tool for singling out the pool which is currently active.
What also changes possibly often is the pollbal.services file. For our use cases we can probably just deploy a new configuration version with puppet, but this kind of a HTTP configuration override feature might be a nice feature for this file too.
How about we actually create a separate project for a tool which polls for a remote URL and makes sure that some configuration in the file system matches the response from that URL? This tool could then be configured to send a refresh signal to pollbal so that pollbal knows to reread the configuration. This same logic could then be also applied for the services file if we require that.
This way we can ignore this feature completely from pollbal, which might be a great idea in terms of keeping the scope manageable.
By default pollbal should receive a file path (by config) where to look for the "pool.conf" file that specifies which of the hashes are active for each pool.
Additionally a separate url and refresh interval can be provided (by config) which makes pollbal overwrite that poll.conf file on each interval if a successful result is returned from the provided url.
This makes it possible to use pollbal as a self contained service and allows configuration by hand if needed.