-
Notifications
You must be signed in to change notification settings - Fork 164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider local configuration #73
Comments
+1 on this.. if anything the configuration should be located in the source data (git) vs transient (consul). |
is it currently possible to have the config locally and have it not be loaded to the consul KV? |
+1, due to ACL I can only write to /prefix/* and as such the default /git2consul/config is not available. |
my reason for not pushing config to the K/V store:
|
Currently git2consul pushes it's configuration (if one is passed) to the Consul KV before pulling and using it. However, this doesn't really buy us anything and can potentially introduce race conditions.
One such case is with multiple instances of git2consul running. If git2consul is running as a service on multiple machines (or containers) and has a
config-file
passed in as well ashalt_on_change
enabled, it will go into a perpetual restart cycle. Every time the service starts, it will push the config to the KV and triggerhalt_on_change
on the other running git2consul service(s), which in turn will restart, push the config, and trigger restarts on its sister services.Another example is with the logger configuration. When git2consul first starts and there is no config seeded yet, the process doesn't use the logging config provided by the user until after it's seeded and read #L79. This means that logging output before
config_reader.read()
's callback (e.g.config_reader.read()
itself andconfig_seeder.set()
) is done with the default logger configuration.Moving the config to be read locally removes complexity, eliminates potential race conditions, and makes it clearer what configuration a running git2consul service is using (though this can be addressed in today's version with
halt_on_change
but introduces other issues).Dynamic configuration (i.e. updating configuration without re-deploying) can still be done with tools like consul-template. The decision of using the KV for dynamic git2consul configuration was done before such tool became available.
The text was updated successfully, but these errors were encountered: