[openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

Arkady_Kanevsky at DELL.com Arkady_Kanevsky at DELL.com
Mon Sep 5 17:56:47 UTC 2016


That is the question of how many releases backwards community is willing to “support”.
The current answer is 1 year. If customer wants something earlier – do it yourself. Or to be precise work with you vendor whose driver you want updated. This creates vendor driver mismatch issues for validation of older version. The only two options I see are 3rd party distros or OpenStack changing its policy.
Former is being done now.
Thus, it works.
Thanks,
Arkady


From: Duncan Thomas [mailto:duncan.thomas at gmail.com]
Sent: Monday, August 22, 2016 3:45 PM
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers


What is the logic for that? It's a massive duplication of effort, and it leads to defacto forks and inconsistencies between clouds - exactly what the OpenStack mission is against.

Many/most of the clouds actually in production are already out of upstream stable policy. The more convergence we can get on what happens after that the better. There are zero advantages I can see to each vendor going it alone.

On 22 Aug 2016 19:31, <Arkady_Kanevsky at dell.com<mailto:Arkady_Kanevsky at dell.com>> wrote:
Sorry if touch 3rd rail.
But should backport bug fixes to older releases be done in distros and not upstream?

-----Original Message-----
From: Walter A. Boring IV [mailto:walter.boring at hpe.com<mailto:walter.boring at hpe.com>]
Sent: Tuesday, August 09, 2016 12:34 PM
To: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

On 08/08/2016 02:28 PM, Ihar Hrachyshka wrote:
> Duncan Thomas wrote:
>
>> On 8 August 2016 at 21:12, Matthew Treinish
>> wrote:
>> Ignoring all that, this is also contrary to how we perform testing in
>> OpenStack.
>> We don't turn off entire classes of testing we have so we can land
>> patches, that's just a recipe for disaster.
>>
>> But is it more of a disaster (for the consumers) than zero testing,
>> zero review, scattered around the internet
>> if-you're-lucky-with-a-good-wind you'll maybe get the right patch
>> set? Because that's where we are right now, and vendors, distributors
>> and the cinder core team are all saying it's a disaster.
>
> If consumers rely on upstream releases, then they are expected to
> migrate to newer releases after EOL, not switch to a random branch on
> the internet. If they rely on some commercial product, then they
> usually have an extended period of support and certification for their
> drivers, so it’s not a problem for them.
>
> Ihar
This is entirely unrealistic. Force customers to upgrade. Good luck
explaining to a bank that in order to get their cinder driver fix in, they have to upgrade their entire OpenStack deployment. Real world customers simply will balk at this all day long.

Walt
>
> ______________________________________________________________________
> ____
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@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?subject:unsubscribe<http://OpenStack-dev-request@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?subject:unsubscribe<http://OpenStack-dev-request@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/20160905/ba81f6e5/attachment.html>


More information about the OpenStack-dev mailing list