Open Stack

Sean McGinnis <sean.mcginnis at gmx.com> 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:

If you would at least provide a public (more or less) stable driver API for  
vendors to use, like neutron does, then your vendors would not need to fork  
the whole Cinder tree. Instead, they would 1) work with community on bug  
fixes while stable/* is supported; 2) once stable/* is EOL, fork it into  
their own repo (on their own premises!) and maintain it from there.  
Consumers will then decide whether they trust the vendor shipped code as  
much as upstream maintained version of it that is now EOL.

Why don't vendors feel like maintaining their drivers out of tree? Is it  
technically possible? Is it too much of a burden?

>
> 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

How would distributions that care about quality determine which one to ship  
in their products? If the former, for as long as it’s supported by  
upstream, then how/when/whether distros are expected to transition to the  
latter branch?

>
> 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.
>

Unless you manage to get it approved for the global policy, I think you  
will effectively make your stable:follows-policy tag obsolete, and then it  
should be removed from your project. Read the requirements:

https://governance.openstack.org/reference/tags/stable_follows-policy.html#requirements

Support phases are part of the stable policy, and so if you don’t mostly  
adhere to their definitions, you should not carry the tag. Which is fine  
with me, it’s up to Cinder team to decide whether it’s worth it.

> 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 would be pushed as a global OpenStack policy, I would voice my  
concerns.

I think Neutron model is much more viable, with vendors untangled from core  
neutron release cycles, and effectively controlling their own destiny by  
relying on (more or less) stable plugin/driver API.

Then each vendor will be able to determine whether carrying new bug fixes  
is more important for them than having the stable:follows-policy tag for  
their deliverable, without compromising the promise the core project  
(Cinder) made with the tag applied.

> 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.
>

Support phases are signalling consumers what to expect from new patch/minor  
releases. Without following the global policy, you leave consumers puzzled  
as to whether the next patch release from a  
widely-advertised-to-be-CVE-only branch will break anything in their driver  
of choice, depending on how a project in question decided to loosen  
supposed-to-be-global stable policy.

> 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.
>
> Thanks!
>
> Sean McGinnis (smcginnis)
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev