Excerpts from Sean Dague's message of 2017-03-15 08:54:55 -0400: > On 03/15/2017 02:16 AM, Clint Byrum wrote: > > Excerpts from Monty Taylor's message of 2017-03-15 04:36:24 +0100: > >> On 03/14/2017 06:04 PM, Davanum Srinivas wrote: > >>> Team, > >>> > >>> So one more thing popped up again on IRC: > >>> https://etherpad.openstack.org/p/oslo.config_etcd_backend > >>> > >>> What do you think? interested in this work? > >>> > >>> Thanks, > >>> Dims > >>> > >>> PS: Between this thread and the other one about Tooz/DLM and > >>> os-lively, we can probably make a good case to add etcd as a base > >>> always-on service. > >> > >> As I mentioned in the other thread, there was specific and strong > >> anti-etcd sentiment in Tokyo which is why we decided to use an > >> abstraction. I continue to be in favor of us having one known service in > >> this space, but I do think that it's important to revisit that decision > >> fully and in context of the concerns that were raised when we tried to > >> pick one last time. > >> > >> It's worth noting that there is nothing particularly etcd-ish about > >> storing config that couldn't also be done with zk and thus just be an > >> additional api call or two added to Tooz with etcd and zk drivers for it. > >> > > > > Combine that thought with the "please have an ingest/export" thought, > > and I think you have a pretty operator-friendly transition path. Would > > be pretty great to have a release of OpenStack that just lets you add > > an '[etcd]', or '[config-service]' section maybe, to your config files, > > and then once you've fully migrated everything, lets you delete all the > > other sections. Then the admin nodes still have the full configs and > > one can just edit configs in git and roll them out by ingesting. > > > > (Then the magical rainbow fairy ponies teach our services to watch their > > config service for changes and restart themselves). > > Make sure to add: > > ... (after fully quiescing, when they are not processing any inflight > work, when they are part of a pool so that they can be rolling restarted > without impacting other services trying to connect to them, with a > rollback to past config should the new config cause a crash). > > There are a ton of really interesting things about a network registry, > that makes many things easier. However, from an operational point of > view I would be concerned about the idea of services restarting > themselves in a non orchestrated manner. Or that a single key set in the > registry triggers a complete reboot of the cluster. It's definitely less > clear to understand the linkage of the action that took down your cloud > and why when the operator isn't explicit about "and restart this service > now". >
It's big and powerful and scary. That's for sure. But it's not _that_ different than an Ansible playbook in its ability to massively complicate or uncomplicate your life with a tiny amount of code. :) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev