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