On 08/06/2016 11:31 AM, Sean McGinnis wrote:
This may mostly be a Cinder concern, but putting it out there to get
wider input.
For some time now there has been some debate about moving third party
drivers in Cinder to be out of tree. I won't go into that too much,
other than to point out one of the major drivers for this desire that
was brought up at our recent Cinder midcycle.
It turned out at least part of the desire to move drivers out of tree
came down to the difficulty in getting bug fixes out to end users that
were on older stable versions, whether because that's what their distro
was still using, or because of some other internal constraint that
prevented them from upgrading.
A lot of times what several vendors ended up doing is forking Cinder to
their own github repo and keeping that in sync with backports, plus
including driver fixes they needed to get out to their end users. This
has a few drawbacks:
1- this is more work for the vendor to keep this fork up to date
2- end users don't necessarily know where to go to find these without
calling in to a support desk (that then troubleshoots a known issue
and hopefully eventually ends up contacting the folks internally that
actually work on Cinder that know it's been fixed and where to get
the updates). Generally a bad taste for someone using Cinder and
OpenStack.
3- Distros that package stable branches aren't able to pick up these
changes, even if they are picking up stable branch updates for
security fixes
4- We end up with a lot of patches proposed against security only stable
branches that we need to either leave or abandon, just so a vendor
can point end users to the patch to be able to grab the code changes
Proposed Solution
-----------------
So part of our discussion at the midcycle was a desire to open up stable
restrictions for getting these driver bugfixes backported. At the time,
we had discussed having new branches created off of the stable branches
specifically for driver bugfixes. Something like:
stable/mitaka > stable/mitaka-drivers
After talking to the infra team, this really did sound like overkill.
The suggestion was to just change our stable policy in regards to driver
bugfix backports. No need to create and maintain more branches. No need
to set up gate jobs and things like that.
So this is a divergence from our official policy. I want to propose
we officially make a change to our stable policy to call out that
drivers bugfixes (NOT new driver features) be allowed at any time.
If that's not OK with other project teams that support any kind of third
party drivers, I will just implement this policy specific to Cinder
unless there is a very strong objection, with good logic behind it, why
this should not be allowed.
This would address a lot of the concerns at least within Cinder and
allow us to better support users stuck on older releases.
I'm open and welcome to any feedback on this. Unless there are any major
concerns raised, I will at least instruct any Cinder stable cores to
start allowing these bugfix patches through past the security only
phase.
The only issue I see with this modified proposal is that it doesn't
address the lifetime of the stable branches. If the plan is to use the
normal stable branch instead of making a special branch, then we also
need to find a way to keep stable branches around for practically
forever (way longer than the typical 12 months).
Those of us dealing with bugfix backports for customers inevitably are
looking at going 3, 4, or 5 releases back with the backports. Therefore
I'd suggest modifying the policy to keep the stable branches around more
or less forever, and when it's no longer to run dsvm jobs on them
(because those jobs WILL eventually break as infra stops maintaining
support for very old releases) then we simply remove those jobs and rely
on vendor CI + minimal upstream tests (pep8, unit tests).
-Ben
Thanks!
Sean McGinnis (smcginnis)
__________________________________________________________________________
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
__________________________________________________________________________
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
