[openstack-dev] [kolla][tripleo] Deprecating config-internal
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). 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? 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
Re: [openstack-dev] [kolla][tripleo] Deprecating config-internal
On Fri, 2015-08-07 at 14:21 +, 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 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
Re: [openstack-dev] [kolla][tripleo] Deprecating config-internal
- 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 +, 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
Re: [openstack-dev] [kolla][tripleo] Deprecating config-internal
On 8/7/15, 8:08 AM, Dan Prince dpri...@redhat.com wrote: On Fri, 2015-08-07 at 14:21 +, 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) Not sure if you missed my response to your earlier post about gaps in kolla related to TripleO but we already have multiple file config feature. Its a a little clunky (our config-external script copies each file individually into the container from the bindmount) but preserves immutability which is criticial imo :) A more detailed response is in my response to your other email regarding Kolla. 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 Nice thanks! 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
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 +, 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-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
