Open Stack

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".

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 (?).

>
> 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/