fuel-dev team mailing list archive

[Sergii Golovatiuk <sgolovatiuk@xxxxxxxxxxxx>]

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 <
dnovakovskiy@xxxxxxxxxxxx> 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     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>
>