----- Original Message ----- From: "James Slagle" <james.sla...@gmail.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@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 <dpri...@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-requ...@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-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
