Open Stack

On Fri, 2015-04-17 at 09:37 -0700, Clint Byrum 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.. ;)

The high level templates don't. All the puppet stuff is nicely
encapsulated in a sub-directory (except for the resource registry which
is a really minor exception). I'm actually really happy with how the
architecture of the Heat templates is evolving to be more pluggable in
the last release.

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

Agree, and I think things are naturally already moving in that
direction.

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