Open Stack

On Thu, 2015-05-07 at 11:22 +0200, Giulio Fidente wrote:
> hi Dan!
> 
> On 05/07/2015 04:32 AM, 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.
> 
> not sure about the meaning of 'resources duplicated' but I think it is 
> safe to say that the pacemaker ifs are there coping mainly with the 
> following two:
> 
> 1. when pacemaker, we don't want puppet to enable/start the service, 
> pacemaker will manage so we need to tell the module not to
> 
> 2. when pacemaker, there are some pacemaker related steps to be 
> performed, like adding a resource into the cluster so that it is 
> effectively monitoring the service status
> 
> in the future, we might need to pass some specific config params to a 
> module only when pacemaker, but that looks like covered by 1) already
> 
> > 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/
> >
> > 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 the change is good, I am assuming we don't want the shared parts 
> to get duplicated into the two .pp though.

So again. Duplicating the puppet class includes doesn't bother me too
much. Some of the logic (perhaps the DB creation) should move over to
puppet-tripleo however. But I would like to see us not go crazy with the
composition layer... using the stackforge/puppet modules directly is
best I think.


Any conversion code in Puppet (functions using split, downcase, etc) I
view as technical debt which should ideally we would eventually be able
to convert within the Heat templates themselves into formats usable by
Hiera directly. Any duplication around that sort of thing would
eventually get cleaned up as Heat gets an extra function or two.

Dan

> 
> What is your idea about those shared parts? To move them into 
> puppet-tripleo? To provision a shared .pp in addition to a 
> differentiated top-level template maybe? Something else?