Michal, I didn’t say we had to run two parallel implementations at the same time to be compliant with this project maturity tag. We have to maintain it in the release for 3 months until we switch to something else if our intent is to switch to something else (at 3 months + 1 picosecond ☺. Reading into the rationale into this, I believe it is to help out all projects provide a feasible backport mechanism to also be complaint with the follows stable policy project maturity tag.
The fact that Heka is an internal service Kolla uses is not a meaningful argument for avoiding the deprecation policy because operators may rely on our internal infrastructure already (e.g. they built their own containers with heka logging) and need a migration path for what is next. Operators need time to move to a new component just as Kolla does. Regards -steve From: Michał Jastrzębski <inc...@gmail.com> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: Thursday, September 29, 2016 at 8:59 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Kolla] Deprecation Policies (related to Heka) notification = of course relase note with information and upgrade info = of course 1 full release of supporting both heka and alternative = not so much On 29 September 2016 at 10:54, Swapnil Kulkarni (coolsvap) <m...@coolsvap.net<mailto:m...@coolsvap.net>> wrote: On Sep 29, 2016 3:06 PM, "Christian Berendt" <bere...@betacloud-solutions.de<mailto:bere...@betacloud-solutions.de>> wrote: > On 29 Sep 2016, at 06:26, Steven Dake (stdake) > <std...@cisco.com<mailto:std...@cisco.com>> wrote: > > If you have a different parsing of the deprecation policy, feel free to > chime in. Heka is only used as an internal component of Kolla and is not provided as a service for the operators. It should be sufficient to replace Heka by something else without deprecating it. Christian. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Kolla is an operator tool and there are multiple tools only internal to deployment. This does not mean we can deprecate tools without operator being notified about it. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto: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<mailto: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
