Open Stack

On 08/09/2016 11:52 AM, Ihar Hrachyshka wrote:
> Walter A. Boring IV <walter.boring at hpe.com> wrote:
>
>> On 08/08/2016 02:28 PM, Ihar Hrachyshka wrote:
>>> Duncan Thomas <duncan.thomas at gmail.com> wrote:
>>>
>>>> On 8 August 2016 at 21:12, Matthew Treinish <mtreinish at kortar.org> 
>>>> 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.
>
> Real world customers will pay for engineering to support their 
> software, either their own or of one of OpenStack vendors. There is no 
> free lunch from upstream here.

   Our customers are already paying us to support them and it's what we 
are doing.  Nobody is asking for a free lunch from upstream.  We are 
simply asking for a way to have a centralized repository that each 
vendor uses to support their drivers.

The problem is how to get customers patches against older drivers and 
then support following that.  We have no place to centrally place our 
patches against our driver other than our forked github account for 
older releases.   This is exactly what the rest of the Cinder driver 
vendors are doing, and is what we are trying to avoid.  The problem even 
gets worse when a customer has a LeftHand array and a SolidFire and/or 
Netapp and/or Pure array.  The customer will have to get fixes from each 
separate repository and monitor each of those for changes in the 
future.   Which fork to they follow?  This is utter chaos from a 
customer perspective as well as a distributor's perspective and is 
terrible for OpenStack users/deployers.


Walt