Skip to content
This repository has been archived by the owner on Oct 6, 2022. It is now read-only.

Are we actually getting any value out of etcd? #165

Closed
stevejhiggs opened this issue Jul 15, 2016 · 6 comments
Closed

Are we actually getting any value out of etcd? #165

stevejhiggs opened this issue Jul 15, 2016 · 6 comments
Labels

Comments

@stevejhiggs
Copy link
Contributor

Does anyone actually use the replication features of etcd?

If not you could switch to something that's more of a known quantity e.g. redis.

In fact if we did stick an api in for the server you could even just use a flat json file, which would make setup a touch easier.

@tombuildsstuff
Copy link
Contributor

I'd probably suggest Postgres over Redis - but the point still stands.

For me at least, etcD seems to be architectural flair - so I've no objections to switching this out

@stevejhiggs
Copy link
Contributor Author

architectural flair - awesome

@andyroyle
Copy link
Contributor

The original concern was making the toggles simple to retrieve (from the client) and readily available (hence the replication for etcd). It was thought that we would run an etcd cluster that spanned multiple datacenters so that apps could read from a local replica, and in the event of a network partition (outside the DC) apps could still get toggles and wouldn't be blocked from starting by etcd being down.

Whether or not anyone uses it that way is another matter 😉

Tbh most of the important stuff we achieved with client-side (i.e. application-side) code (caching toggles, default values etc).

@chriscartlidge
Copy link
Contributor

I did question this myself when working on Hobknob for the first time as it does seem to be overkill. I do like the suggestion of Postgres but is the time required to switch to Postgres/Anything else worth it... What benefit aim I getting out of it apart from it being a bit more familiar ?

Internally we have a roadmap to upgrade etcd to version 3.0 within the next month. That is my preferred option, unless any other main contributors have a strong option not to continue with etcd.

@tombuildsstuff
Copy link
Contributor

Just to follow up here - I've just pushed PR #179. In particular this would both allow us to support one or more back-ends - potentially even having the API as a 'backend' for the server as discussed in #154, but I'm not so keen on the latter.

It's been a little while - but has anyone had time to reflect on this? Internally we've been bashing around the idea of using Consul instead of etcD for this purpose?

@chriscartlidge
Copy link
Contributor

Hey @tombuildsstuff have you guys had any thought about moving over to consul ?

We upgrade to the latest etcd a few months ago and found it to be a lot less memory leaky than the previous one we were using.

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

No branches or pull requests

5 participants