Open Stack

I would think there's a 3rd implementation on the horizon already.... The abstraction might allow easy docker integration...

Thanks,
Kevin
________________________________________
From: Dan Prince [dprince at redhat.com]
Sent: Tuesday, April 21, 2015 12:53 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO] on supporting multiple implementations of tripleo-heat-templates

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-request at 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-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev