Open Stack

On Thu, 2015-05-07 at 10:26 -0400, Jay Dobies wrote:
> >>> 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'm not sure there is a better way to architect it that doesn't use the
resource registry. Heat doesn't support get_file: {get_param:
ManifestName} so we can't dynamically select an alternate template via a
parameter either.

We enable Puppet by changing the resource registry. Additionally, it is
very likely other things (network architecture related) are going to
make heavy use of the resource registry as well.

Yes, it is different from some of the other feature parameters... but I
think that is probably okay. In this regard maybe pacemaker is more of
an overlay rather than something you just enable via a parameter.

Dan

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