On Thu, 2015-05-07 at 09:10 -0400, Jay Dobies wrote:
>
> On 05/07/2015 06:01 AM, Giulio Fidente wrote:
> > On 05/07/2015 11:15 AM, marios wrote:
> >> On 07/05/15 05:32, Dan Prince wrote:
> >
> > [..]
> >
> >>> Something like this:
> >>>
> >>> https://review.openstack.org/#/c/180833/
> >>
> >> +1 I like this as an idea. Given we've already got quite a few reviews
> >> in flight making changes to overcloud_controller.pp (we're still working
> >> out how to, and enabling services) I'd be happier to let those land and
> >> have the tidy up once it settles (early next week at the latest) -
> >> especially since there's some working out+refactoring to do still,
> >
> > +1 on not block ongoing work
> >
> > as of today a split would cause the two .pp to have a lot of duplicated
> > data, making them not better than one with the ifs IMHO
>
> I'm with Giulio here. I'm not as strong on my puppet as everyone else,
> but I don't see the current approach as duplication, it's just passing
> in different configurations.
What about this isn't duplication?
if $enable_pacemaker {
class { 'neutron::agents::metering':
manage_service => false,
enabled => false,
}
pacemaker::resource::service
{ $::neutron::params::metering_agent_service:
clone => true,
require => Class['::neutron::agents::metering'],
}
} else {
include ::neutron::agents::metering
}
-------
We'll have this for basically all the pacemaker enabled services. It is
already messy. It will get worse.
Again, One of the goals of our current TripleO puppet manifests
architecture was that our role scripts would be just 'include'
statements for the related puppet classes. Using Hiera as much as
possible, etc. Having two controller templates which have the same
include statements isn't ideal, but I think it is better than the mess
we've got now.
Actually seeing the pacemaker stuff implemented we have a lot of bioler
plate stuff now going into the templates. All the conditional
manage_service => false, enabled => false could be simply stashed into a
new Hiera data file that only gets included w/ that implementation. This
makes the pacemaker version cleaner... something you just can't do with
the current implementation.
Unfortunately I don't know of a way to do any of this without the
resource registry. If it is concerning it would for example be quite
easy for someone developing a product to simply make this resource
registry by default (thus leaving pacemaker on, always). No tuskar or
template changes would be required for this.
Dan
>
> > we should probably move out of the existing .pp the duplicated parts
> > first (see my other email on the matter)
>
> My bigger concern is Tuskar. It has the ability to set parameters. It's
> hasn't moved to a model where you're configuring the overcloud through
> selecting entries in the resource registry. I can see that making sense
> in the future, but that's going to require API changes.
>
> __________________________________________________________________________
> 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
