[openstack-dev] [TripleO] on supporting multiple implementations of tripleo-heat-templates

Clint Byrum clint at fewbar.com
Fri Apr 17 19:07:49 UTC 2015


Excerpts from James Slagle's message of 2015-04-17 10:49:48 -0700:
> On Fri, Apr 17, 2015 at 12:37 PM, Clint Byrum <clint at fewbar.com> wrote:
> > Excerpts from Giulio Fidente's message of 2015-04-17 06:21:28 -0700:
> >> Hi,
> >>
> >> the Heat/Puppet implementation of the Overcloud deployment seems to be
> >> surpassing in features the Heat/Elements implementation.
> >>
> >> The changes for Ceph are an example, the Puppet based version is already
> >> adding features which don't have they counterpart into Elements based.
> >>
> >> Recently we started working on the addition of Pacemaker into the
> >> Overcloud, to monitor the services and provide a number of 'auto
> >> healing' features, and again this is happening in the Puppet
> >> implementation only (at least for now) so I think the gap will become
> >> bigger.
> >>
> >> Given we support different implementations with a single top-level
> >> template [1], to keep other templates valid we're forced to propagate
> >> the params into the Elements based templates as well, even though there
> >> is no use for these there, see for example [2].
> >>
> >> The extra work itself is not of great concern but I wonder if it
> >> wouldn't make sense to deprecate the Elements based templates at this
> >> point, instead of keep adding there unused parts? Thoughts?
> >>
> >
> > In a perfect world, templates wouldn't have implementation details like
> > puppet-anything in them. We all know that isn't true, but in a perfect
> > world.. ;)
> >
> > I was just wondering the other day if anybody is relying on the non-puppet
> > jobs anymore. I think from my view of things, the "elements" approach
> > can be deprecated and removed if nobody steps up to maintain them.
> 
> I think we should consider deprecation if it's clear no one is
> maintaining them. The elements approach does offer testing
> installation from source instead of packages, which eventually
> wouldn't be tested any longer if we were to deprecate. It also has the
> nice benefit of being able to CI test individual project reverts or
> pins to see what might be causing failures. Maybe we could translate
> these features somehow to the puppet world.
> 
> Not to put off the discussion, but I just added this as something to
> discuss at the Summit[1]. Between now and then we can continue to
> gauge the interest of maintaining the elements approach.
>

So, we could replace the pip-from-source with jobs that just do that
in the check/gate of each project. It should be a quick test, and one
that I don't think anybody would mind being able to run themselves,
especially when adding entry points or modifying structure.

As far as testing individual reverts.. that is useful, however, as the
maintenance level goes down, the value of those results will as well. So
without full-time maintainers, I don't think it will be a positive
for long.



More information about the OpenStack-dev mailing list