[openstack-dev] [TripleO] on supporting multiple implementations of tripleo-heat-templates
James Slagle
james.slagle at gmail.com
Fri Apr 17 17:49:48 UTC 2015
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.
[1] https://etherpad.openstack.org/p/tripleo-liberty-proposed-sessions
>
> __________________________________________________________________________
> 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
--
-- James Slagle
--
More information about the OpenStack-dev
mailing list