You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I want to use the git-sniffing capabilities of git2consul to interpret files and changes as configurations, but I don't want a dumb KV store, and for various reasons can't use consul, e.g. see https://groups.google.com/forum/#!topic/consul-tool/qN2ZilnFx00 for one such reason. I want a KV store which is a server that I control, so I can handle key creation, updates, and deletion whichever way I see fit.
For that reason, I'm wondering if go-git2consul could be architected in a modular fashion, where one project is simply responsible for interfacing with the version-control repository in the expected ways, another is responsible for interfacing with the KV store, and there is a framework project which can manage the executable/daemon, its own configuration, and load the libraries for interfacing with aforementioned subsystems?
If done with modularity, this project would be extensible to other version control systems and other KV stores besides consul, e.g. a webhook.
I saw in the future section of the README: File format backend. Is this something related?
If you like the idea, and this is something I can help with, please let me know.
The text was updated successfully, but these errors were encountered:
Unfortunately, this is something that is outside the scope of git2consul. The file format backend refers to https://github.com/Cimpress-MCP/git2consul#expand_keys with a generic interface implementation that can be used to parse any arbitrary file format.
I want to use the git-sniffing capabilities of git2consul to interpret files and changes as configurations, but I don't want a dumb KV store, and for various reasons can't use consul, e.g. see https://groups.google.com/forum/#!topic/consul-tool/qN2ZilnFx00 for one such reason. I want a KV store which is a server that I control, so I can handle key creation, updates, and deletion whichever way I see fit.
For that reason, I'm wondering if go-git2consul could be architected in a modular fashion, where one project is simply responsible for interfacing with the version-control repository in the expected ways, another is responsible for interfacing with the KV store, and there is a framework project which can manage the executable/daemon, its own configuration, and load the libraries for interfacing with aforementioned subsystems?
If done with modularity, this project would be extensible to other version control systems and other KV stores besides consul, e.g. a webhook.
I saw in the future section of the README: File format backend. Is this something related?
If you like the idea, and this is something I can help with, please let me know.
The text was updated successfully, but these errors were encountered: