Hi Dmitriy, The algorithm you described is correct. Currently, Fuel is really close to the procedure you describe.
1. Remove controller from environment Puppet will remove the controller from files, services re-triggered. Though, the case requires one manual step from operator as corosync can't remove/add new node to redundant ring protocol on the fly. 2. Not a problem and already implemented. 3. Everything should work fine except insertion a new node to corosync. We have a blueprint to tune/fix corosync additional/removal nodes. I hope this functionality will be implemented soon. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Mon, Jul 28, 2014 at 3:49 PM, Dmitriy Novakovskiy < [email protected]> wrote: > Hi Fuelers, > > I recently got a question from one of the prospects - what should Fuel > user do if one of the OpenStack controllers fails (completely) and there's > a need to replace it with new box. > > My educated guess was: > 1. Remove controller from the environment in Fuel UI (*Q1:* is it > actually possible? assuming that server is out and Fuel won't be able to do > cleanup) > 2. Get new controller discovered > 3. Add new controller to the environment in Fuel UI (*Q2:* how does this > happen right now? Does Fuel re-reploy all controllers? Will cloud > experience services downtime? Will DB state be preserved?) > > Is it anywhere close to reality? Do we actually test the cases like that? > > Thanks, > > --- > Regards, > > *Dmitriy Novakovskiy* > Sales Engineer, Mirantis EMEA > > *Skype:* dmitriy.novakovskiy > *Operating from:* Ukraine > > -- > Mailing list: https://launchpad.net/~fuel-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~fuel-dev > More help : https://help.launchpad.net/ListHelp > >
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
