On Fri, 2015-04-17 at 15:21 +0200, Giulio Fidente wrote: > 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].
This was done intentionally when adding the new puppet templates. The idea was that tripleo-heat-templates was defining a high level interface that could be used to provision and configure a cloud with multiple backends (tripleo-image-elements and or puppet being the current options). It was actually a bit more work to do it this way but the idea is that we are refining our interfaces to be more generic and correct. In doing the puppet work we actually discovered lots of data that was being copied into various roles that wasn't needed. And having the working tripleo-image-elements implementation to begin with was also a great help to speed the puppet stuff along. > > 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? You aren't really adding that many unused parts. Just a parameter here and there right? And this is just to keep the CI jobs happy. With regards to the specific templates for triple-image-elements for configuration long term I'm not sure where they are headed. I don't think there is as much interest in maintaining them so perhaps we should deprecate them... However, I would like to see us maintain the abstractions we have in place in tripleo-heat-templates should another implementation come along besides Puppet. To me this is sort of the essence of TripleO (defining an interface to deploy a cloud). And if you are suggesting we get rid of tripleo-image-elements just so we can then go and remove these abstractions then I think it might be a step in the wrong direction. In other words... regardless of what happens to the maintenance of the tripleo-image-elements (and any associated templates) lets keep a structure that supports multiple backends. Yes, it may cost a bit of extra wiring here and there but I think it is worth the effort. > Thoughts? > > 1. > https://github.com/openstack/tripleo-heat-templates/blob/master/overcloud-without-mergepy.yaml > 2. https://review.openstack.org/#/c/173773 > > __________________________________________________________________________ > 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