[openstack-dev] [kolla][tripleo] Deprecating config-internal

James Slagle james.slagle at gmail.com
Fri Aug 7 15:20:59 UTC 2015


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'm going to defer to others on this one and support their consensus,
given that I haven't been able to be as closely involved with it as I
would have liked. I'll leave it up to Dan, Ryan, and Ian to provide
the right input here. From a cursory glance, config-external sounds
like the right move to me.

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



More information about the OpenStack-dev mailing list