|Doozer Meeting Notes||Brian Ketelsen||2/28/13 11:38 AM|
Thank you to everyone who attended. Here are my terrible notes from the meeting.
We started by discussing our own use cases of Doozer:
Bitly uses it as a KV storage system of last resort to keep shortened keys in one last system of record in the case of local storage failure on front end machines.
Skynet / Clarity Services uses Doozer as a service coordination layer, and it seems that Soundcloud has a very similar use case.
We moved on to discuss issues with Doozer that we'd like to address. In no particular order:
1. Needs better config management
2. Reliability issues
3. No persistence
4. Needs better scripting (of startup?)
5. Reliability on node failure when nodes restart on same port / IP address
6. DzNS is confusing
7. Needs better web admin interface
8. Logging too verbose
We discussed the best ways to move forward as a group. Earlier email proposal is copied below:
We were just discussing this internally. How about we use some basic github tools to manage what gets done and how.
Everyone seems to agree that this is a good approach.
The "HA" github repo will remain the canonical Doozer repository, and all pull requests will be applied against it. We will open issues to reflect those we found in our discussion today, and any more that are identified along the way.
Our first task is to get the HA repo up to Go 1.0.3/1.1 building standards.
If I've missed anything, I apologize, it's hard to keep notes and participate at the same time, and I'm a much better typist than I am a hand-writer.
Thank you again to Keith for joining us, and for giving his blessing for this work to continue. We're all here because we find tremendous value in Doozer.
Yours in high availability,