Something like this:
https://review.openstack.org/#/c/180833/
I'm not convinced this is a good user experience though. You have
configuration effectively in two places. If you want to enable Galera,
or enable ceph storage, it's a parameter. But not pacemaker. To enable
that, you have to look in the resource registry instead.
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-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
__________________________________________________________________________
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
