On Dec 12, 2012, at 12:52 PM, Mike Schultz <mike.schu...@gmail.com> wrote:
> Ok, that makes sense and it's probably workable, but, it's still more awkward > than having code and configuration deployed together to individual machines. > > For example, for a deploy of new software/config we need to 1) first upload > config to zK. then 2) deploy new software to the nodes. > > What about the span of time between 1) and 2)? If a box bounces during this > time it will come up with the wrong config. Or what if 2) goes awry and > some boxes succeed and some fail? It could be very complicated to recover > from that. Yeah, that's the only sticky spot I was thinking about. But i figured that in general, if a box goes down, you would upgrade it before bringing it back up. > > Another use case is, I may want to push a new software/config to a single > box for a smoke test before rolling to all nodes in production (some might > call this testing in production but it's just real world safety). You might file a feature request - there are various things you could consider - perhaps allowing a core that is part of a collection to override the collection config and point to a different one in zookeeper. Working with local configs today is a little scary in that it might tie our hands a bit in terms of what we need to support in the future and other features we want to add. > > I guess at the end of the day, what I don't understand is, given that I need > to roll new software bits to individual nodes for the deployment of new > software, what good does keeping config in zk do for me? Why not just keep > the config with the software and roll it at the same time? It ensures that all the nodes are using the same config and one is not somehow off. If you have ever juggled configs that should be the same across 100 nodes, you have probably screwed things up here and there. And updating a setting means updating 100 files, etc. Be sure you didn't miss one :) - Mark
