On 08/09/2016 11:52 AM, Ihar Hrachyshka wrote:
Walter A. Boring IV <walter.bor...@hpe.com> wrote:
On 08/08/2016 02:28 PM, Ihar Hrachyshka wrote:
Duncan Thomas <duncan.tho...@gmail.com> wrote:
On 8 August 2016 at 21:12, Matthew Treinish <mtrein...@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
__________________________________________________________________________
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
