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, 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev