Michael S. Fischer
Michael S. Fischer
It's been well over a year now since this issue was last revisited. Can we get an update, please?
Storing the configuration in Consul has some practical issues, however. By storing the configuration in the database, you sacrifice reproducibility and auditability of the configuration. You can use automated processes...
Auditing is not identical to ACLs. And configuration file histories are significantly easier to audit and store in change control than database manipulations. I'm not suggesting that configurations stored in...
> Storing the running config in consul is necessary. It cannot be worked around Respectfully, I think you mean "I don't want to," not that you can't do it. If...
First, the documentation doesn't say anything about automated failover, or where it must run (and I wouldn't want to run this on a Consul server anyway since alerting is a...
> Not using the KV makes me think of phrases like: "Don't look a gift horse in the mouth" or "Don't reinvent the wheel". Consul supplies a ready solution to...
+1 I'd like to add hysteresis as well; a noisy service (frequent fail/good cycling within a small time window) should not result in an alert storm. Alerts should be windowed....
What's better about EntryKit? Can you point me to the project?
What's the latest on this?
> Implementing separate exceptions for the connection-timeout and the command-timeout will be a bit tricky to do in a backwards-compatible way, since consumers of this library have historically relied on...