Open Stack

>>> 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>