Skip to content
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

Open
calvn opened this issue Apr 11, 2016 · 4 comments
Open

Consider local configuration #73

calvn opened this issue Apr 11, 2016 · 4 comments

Comments

@calvn
Copy link
Contributor

calvn commented Apr 11, 2016

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 as halt_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 trigger halt_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 and config_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.

@skyscooby
Copy link

+1 on this.. if anything the configuration should be located in the source data (git) vs transient (consul).

@paperpunk
Copy link

is it currently possible to have the config locally and have it not be loaded to the consul KV?

@ghost
Copy link

ghost commented Nov 9, 2017

+1, due to ACL I can only write to /prefix/* and as such the default /git2consul/config is not available.
(--config-key is supposed to help here, but seems to not work correctly, always returns Config value is not valid JSON: undefined.)

@BobVanB
Copy link

BobVanB commented Nov 14, 2017

my reason for not pushing config to the K/V store:
security issue with use of a private repo?

{
  "version": "1.0",
  "repos" : [{
    "name" : "myname",
    "expand_keys" : true,
    "expand_keys_diff" : true,
    "url" : "http://username:[email protected]",
    "ignore_repo_name" : true,
    "ignore_file_extension" : true,
    "include_branch_name" : false,
    "branches" : ["mybranch"],
    "hooks": [{
      "type" : "polling",
      "interval" : "1"
    }]
  }]
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants