Open Stack

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 <inc007 at gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Thursday, September 29, 2016 at 8:59 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at 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)
<me at coolsvap.net<mailto:me at coolsvap.net>> wrote:
On Sep 29, 2016 3:06 PM, "Christian Berendt"
<berendt at betacloud-solutions.de<mailto:berendt at betacloud-solutions.de>> wrote:

> On 29 Sep 2016, at 06:26, Steven Dake (stdake) <stdake at cisco.com<mailto:stdake at 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-request at lists.openstack.org<mailto:OpenStack-dev-request at 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-request at lists.openstack.org<mailto:OpenStack-dev-request at 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-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160929/5edf586e/attachment-0001.html>