Open Stack

----- Original Message -----
From: "James Slagle" <james.slagle at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Sent: Friday, August 7, 2015 11:20:59 AM
Subject: Re: [openstack-dev] [kolla][tripleo] Deprecating config-internal

On Fri, Aug 7, 2015 at 11:08 AM, Dan Prince <dprince at redhat.com> wrote:
> On Fri, 2015-08-07 at 14:21 +0000, Steven Dake (stdake) wrote:
>> James and Dan,
>>
>> During the ansible-multi spec process that James Slagle reviewed,
>> there was a serious commitment by the Kolla core team to maintain
>> config-internal, pretty much for the tripleo use case.  We didn’t
>> want to leave our partner projects in the lurch and at the time
>> Ryan/Ian’s implementation of tripleo containers were based upon
>> config-internal.  It would be immensely helpful for Kolla if we could
>> deprecate that model during l3, and I think Dan’s judgement is to use
>> config-external (with some additional beefing up of some of the
>> containers like snmp+ceilometer compute plus possibly some other
>> minor solveable requirements).
>
> Correct. I'm heavily leaning towards using config-external assuming we
> can make it support use of multiple config files, and then have a way
> to tie that into starting the service with the same files (neutron ml2
> agent for example uses multiple configs)
>
>>
>> Can I get a general ack from the tripleo community that deprecating
>> config-internal is a-ok so we can just remove it before being stuck
>> with it for Liberty?
>
> ++ from me

I think using external config works well. The existing puppet recipes
are very advanced so it would provide more config options available to use
with the containerized services.

+1
-Ryan

>
>>   I don’t want to deprecate something we committed to supporting if
>> there is still requirement from the tripleo community to maintain it,
>> but it would make our lives a lot easier and thus far the config
>> -internal case is really only for TripleO.
>>
>> Comments welcome.
>>
>> Thanks!
>> -steve
>
> __________________________________________________________________________
> 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
--

__________________________________________________________________________
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