Open Stack

On Thu, 2015-05-07 at 12:15 +0300, marios wrote:
> On 07/05/15 05:32, Dan Prince wrote:
> > Looking over some of the Puppet pacemaker stuff today. I appreciate all
> > the hard work going into this effort but I'm not quite happy about all
> > of the conditionals we are adding to our puppet overcloud_controller.pp
> > manifest. Specifically it seems that every service will basically have
> > its resources duplicated for pacemaker and non-pacemaker version of the
> > controller by checking the $enable_pacemaker variable.
> > 
> > After seeing it play out for a couple services I think I might prefer it
> > better if we had an entirely separate template for the "pacemaker"
> > version of the controller. One easy way to kick off this effort would be
> > to use the Heat resource registry to enable pacemaker rather than a
> > parameter.
> > 
> > Something like this:
> > 
> > https://review.openstack.org/#/c/180833/
> 
> +1 I like this as an idea. Given we've already got quite a few reviews
> in flight making changes to overcloud_controller.pp (we're still working
> out how to, and enabling services) I'd be happier to let those land and
> have the tidy up once it settles (early next week at the latest) -
> especially since there's some working out+refactoring to do still,

My preference would be that we not go any further down the path of using
$enable_pacemaker in the overcloud_controller.pp template.

I don't think it would be that hard to convert existing reviews to use
the new file would it? And removing the conditionals would just make it
read more cleanly too.

Dan

> 
> thanks, marios
> 
> > 
> > If we were to split out the controller into two separate templates I
> > think it might be appropriate to move a few things into puppet-tripleo
> > to de-duplicate a bit. Things like the database creation for example.
> > But probably not all of the services... because we are trying as much as
> > possible to use the stackforge puppet modules directly (and not our own
> > composition layer).
> > 
> > I think this split is a good compromise and would probably even speed up
> > the implementation of the remaining pacemaker features too. And removing
> > all the pacemaker conditionals we have from the non-pacemaker version
> > puts us back in a reasonably clean state I think.
> > 
> > Dan
> > 
> > 
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev