> 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
