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