Open Stack

On Fri, 2015-05-08 at 11:41 -0400, James Slagle wrote:
> On Thu, May 7, 2015 at 5:46 PM, Giulio Fidente <gfidente at redhat.com> wrote:
> > On 05/07/2015 07:35 PM, Dan Prince wrote:
> >>
> >> On Thu, 2015-05-07 at 17:36 +0200, Giulio Fidente wrote:
> >>>
> >>> On 05/07/2015 03:31 PM, Dan Prince wrote:
> >>>>
> >>>> On Thu, 2015-05-07 at 11:22 +0200, Giulio Fidente wrote:
> >
> >
> > [...]
> >
> >>> on the other hand, we can very well get rid of the ifs today by
> >>> deploying *with* pacemaker in single node scenario as well! we already
> >>> have EnablePacemaker always set to true for dev purposes, even on single
> >>> node
> >>
> >>
> >> EnablePacemaker is set to 'false' by default. IMO it should be opt-in:
> >>
> >>
> >> http://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=1f7426a014f0f83ace4d2b3531014e22f7778b4d
> >
> >
> > sure that param is false by default, but one can enable it and deploy with
> > pacemaker on single node, and in fact many people do this for dev purposes
> >
> > before that change, we were even running CI on single node with pacemaker so
> > as a matter of fact, one could get rid of the conditionals in the manifest
> > today by just assuming there will be pacemaker
> 
> This is the direction I thought we were moving. When you deploy a
> single controller, it is an HA cluster of 1. As opposed to just not
> using pacemaker entirely. This is the model we did previously for HA
> and I thought it worked well in that it got everyone testing and using
> the same code path.
> 
> I thought the EnablePacemaker parameter was more or less a temporary
> thing to get us over the initial disruption of moving things over to
> pacemaker.

I personally think there may be value in having an option to deploy
without Pacemaker. I would very much like to see TripleO maintain an
option that supports that. The initial goal of EnablePacemaker (as I
understood it) was just this. To support deploying with and without
Pacemaker.

The talk in this thread is largely about the stylistic concerns of using
the $enable_pacemaker boolean within the same manifest and the
maintenance burden this is going to cause. Simply stated it seems
cleaner to just split things out into separate templates based upon the
pacemaker and non-pacemaker version. Given that our goal is to strive
towards minimal manifests (with just includes) this should be a nice
middle ground.

With regards to TripleO upstream defaults I suppose we need more
discussion about this. My understanding was that traditionally TripleO
has been in the keepalived/HAProxy camp for VIP management. Use of
EnablePacemaker would (currently) disable this.

>From a product prospective a company could take either approach and run
w/ it as their default implementation. I think it is also fine for one
approach to evolve ahead of the other.

Dan

> 
> >
> > this said, I prefer myself to leave some "air" for a (future?) non-pacemaker
> > scenario, but I still wanted to point out the reason why the conditionals
> > are there in the first place
>