← Back to team overview

fuel-dev team mailing list archive

Re: [fuel-dev] single node HA controllers proposal

 

+1 for supporting only HA mode in Fuel.

During Murano & Fuel integration we experienced whole bunch of bugs
introduced with deployment differences between this two modes, so I am
completely agree with Dmitry.


On Tue, Mar 11, 2014 at 12:02 AM, David Easter <deaster@xxxxxxxxxxxx> wrote:

> +1
>
> As long as you can do a 1-controller installation, it would be good for
> both customers and dev to have the required step to pick HA vs. non-HA
> removed.   It also removes the chance that someone picks the wrong one in
> the wizard (since we'd remove it from the wizard completely).
>
> Thanks,
>
> - David J. Easter
>   Product Line Manager
>
>
> From: Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>
> Date: Monday, March 10, 2014 at 6:31 AM
> To: Vladimir Kuklin <vkuklin@xxxxxxxxxxxx>
> Cc: "fuel-dev@xxxxxxxxxxxxxxxxxxx" <fuel-dev@xxxxxxxxxxxxxxxxxxx>
> Subject: Re: [Fuel-dev] [fuel-dev] single node HA controllers proposal
>
> > you will still need to do some node cross-orchestration
> It contradicts to Andrew's experiments (start of the thread), where he was
> able to add 2nd & 3rd controller. Anyway, we still don't miss anything if
> we drop simple mode, right?
> a) You can do 1-node controller install
> b) You can do 3-node controller install
>
> I vote for removing simple mode, as the use case (scale down to 1
> controller) can be covered with 1 controller choosing HA mode.
>
> Thanks,
>
>
> On Sun, Mar 9, 2014 at 9:51 PM, Vladimir Kuklin <vkuklin@xxxxxxxxxxxx>wrote:
>
>> Guys, handling simple mode in the same way as handling HA mode is
>> possible, but after you add controllers, you will still need to do some
>> node cross-orchestration, e.g. updating haproxy nodes or mysql configs.
>> Thus it still faces the same problem - Granular deployment and Much More
>> Advanced Orchestrator is needed.
>>
>>
>> On Sat, Mar 8, 2014 at 2:34 AM, Dmitry Borodaenko <
>> dborodaenko@xxxxxxxxxxxx> wrote:
>>
>>> On Fri, Mar 7, 2014 at 4:03 AM, Sergey Vasilenko
>>> <svasilenko@xxxxxxxxxxxx> wrote:
>>> > I do not sure, that it's a good idea.
>>> > Usualy, most of anything new things, we developing and testing under
>>> simple
>>> > configuration. And after it scale to HA configurations.
>>>
>>> I think it is actually a very BAD idea to develop using a
>>> configuration that is significantly different from production.
>>>
>>> Every time you increase the time interval between introducing a bug
>>> (i.e. developing) and finding a bug (i.e. testing), the cost of fixing
>>> the bug increases exponentially. You no longer remember what you've
>>> changed, you piled other changes on top of incorrect code, you
>>> impacted other engineers who encountered your bug and now have to
>>> figure out that it wasn't their changes causing problems, and so on.
>>>
>>> > Simple configuration gives us low time of deploy,
>>>
>>> Using HA configuration will make us finally pay some attention to the
>>> time it takes to deploy HA and fix it. It's not a fundamental problem,
>>> we're actually doing something wrong here and we should figure it out.
>>>
>>> > possibility of don't use
>>> > buggy Galera, songle-node AMQP. Works with "simple"
>>> > configuration we can don't distractions to HA ussues.
>>>
>>> These are not distractions, you will encounter all these issues before
>>> you can release. And it will be much easier to fix them immediately
>>> after they are introduced, not 1 week before code freeze.
>>>
>>> > One of most typical
>>> > examples -- migration to the next openstack version.
>>>
>>> It is even more important for Icehouse. If we encounter Icehouse bugs
>>> that break HA before Icehouse is released (5 weeks from now), we might
>>> get them fixed upstream instead of having to carry our own patch
>>> series after the release.
>>>
>>> --
>>> Dmitry Borodaenko
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Senior Deployment Engineer,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 45bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com <http://www.mirantis.ru/>
>> www.mirantis.ru
>> vkuklin@xxxxxxxxxxxx
>>
>> --
>> 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
>>
>>
>
>
> --
> Mike Scherbakov
> #mihgen
> -- Mailing list: https://launchpad.net/~fuel-dev Post to :
> fuel-dev@xxxxxxxxxxxxxxxxxxx Unsubscribe : https://launchpad.net/~fuel-devMore help :
> https://help.launchpad.net/ListHelp
>
> --
> 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
>
>


-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelikyan@xxxxxxxxxxxx

+7 (495) 640-4904, 0261
+7 (903) 156-0836

Follow ups

References