Looks like majority +1ed. Let's go for it.
On Tue, Mar 11, 2014 at 1:09 PM, Serg Melikyan <[email protected]>wrote: > +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 <[email protected]>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 <[email protected]> >> Date: Monday, March 10, 2014 at 6:31 AM >> To: Vladimir Kuklin <[email protected]> >> Cc: "[email protected]" <[email protected]> >> 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 <[email protected]>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 < >>> [email protected]> wrote: >>> >>>> On Fri, Mar 7, 2014 at 4:03 AM, Sergey Vasilenko >>>> <[email protected]> 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 : [email protected] >>>> 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 >>> [email protected] >>> >>> -- >>> Mailing list: https://launchpad.net/~fuel-dev >>> Post to : [email protected] >>> 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 : >> [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 >> >> > > > -- > Serg Melikyan, Senior Software Engineer at Mirantis, Inc. > http://mirantis.com | [email protected] > > +7 (495) 640-4904, 0261 > +7 (903) 156-0836 > -- Mike Scherbakov #mihgen
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
