fuel-dev team mailing list archive

[David Easter <deaster@xxxxxxxxxxxx>]

+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 <tel:%2B7%20%28495%29%20640-49-04>
> +7 (926) 702-39-68 <tel:%2B7%20%28926%29%20702-39-68>
> Skype kuklinvv
> 45bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com <http://www.mirantis.ru/>
> www.mirantis.ru <http://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-dev
More help   : https://help.launchpad.net/ListHelp