Open Stack

On Thu, 2015-05-07 at 11:56 +0200, Jiří Stránský wrote:
> Hi Dan,
> 
> On 7.5.2015 04: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.
> 
> +1
> 
> >
> > 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/
> 
> I have two mild concerns about this approach:
> 
> 1) We'd duplicate the logic (or at least the inclusion logic) for the 
> common parts in two places, making it prone for the two .pp variants to 
> get out of sync. The default switches from "if i want to make a 
> difference between the two variants, i need to put in a conditional" to 
> "if i want to *not* make a difference between the two variants, i need 
> to put this / include this in two places".

The goal for these manifests is that we would just be doing 'include's
for various stackforge puppet modules. If we have
'include ::glance::api' in two places that doesn't really bother me.
Agree that it isn't ideal but I don't think it bothers me too much. And
the benefit is we can get rid of pacemaker conditionals for all the
things.

> 
> 2) If we see some other bit emerging in the future, which would be 
> optional but at the same time "omnipresent" in a similar way as 
> Pacemaker is, we'll see the same if/else pattern popping up. Using the 
> same solution would mean we'd have 4 .pp files (a 2x2 matrix) doing the 
> same thing to cover all scenarios. This is a somewhat hypothetical 
> concern at this point, but it might become real in the future (?).

Sure. It could happen. But again maintaining all of those in a single
file could be quite a mess too. And if we are striving to set all or our
Hiera data in Heat (avoiding use of some of the puppet functions we now
make use of like split, etc) this would further de-duplicate it I think.

Again having duplication that includes just the raw puppet classes
doesn't bother me too much.

> 
> >
> > 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 our restraint from having a composition layer (extracting things 
> into puppet-tripleo) is what's behind my concern no. 1 above. I know one 
> of the arguments against having a composition layer is that it makes 
> things less hackable, but if we could amend puppet modules without 
> rebuilding or altering the image, it should mitigate the problem a bit 
> [1]. (It's almost a matter that would deserve a separate thread though :) )
> 
> >
> > 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
> >
> 
> An alternative approach could be something like:
> 
> if hiera('step') >= 2 {
>      include ::tripleo::mongodb
> }
> 
> and move all the mongodb related logic to that class and let it deal 
> with both pacemaker and non-pacemaker use cases. This would reduce the 
> stress on the top-level .pp significantly, and we'd keep things 
> contained in logical units. The extracted bits will still have 
> conditionals but it's going to be more manageable because the bits will 
> be a lot smaller. So this would mean splitting up the manifest per 
> service rather than based on pacemaker on/off status. This would require 
> more extraction into puppet-tripleo though, so it kinda goes against the 
> idea of not having a composition layer. It would also probably consume a 
> bit more time to implement initially and be more disruptive to the 
> current state of things.
> 
> At this point i don't lean strongly towards one or the other solution, i 
> just want us to have an option to discuss and consider benefits and 
> drawbacks of both, so that we can take an informed decision. I think i 
> need to let this sink in a bit more myself.
> 
> 
> Cheers
> 
> Jirka
> 
> [1] https://review.openstack.org/#/c/179177/
> 
> __________________________________________________________________________
> 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