Open Stack

On 3/24/22 10:53 AM, Jeremy Stanley wrote:
> [I'm leaving you in Cc since you don't seem to be subscribed to the
> mailing list.]
> 
> On 2022-03-24 12:33:28 +0000 (+0000), Karthik Viswanath wrote:
> [...]
>> Given that this has direct revenue impact for DataCore and is time
>> sensitive, we request the community to approve our request to add
>> Cinder driver patch to 16.x maintenance releases ( mainly for
>> Trains branch).
> 
> I can't speak for the Cinder maintainers and their backport
> policies, but from a release perspective there will be no further
> 16.x releases of Cinder. The stable/ussuri branch (where 16.x
> releases were made) passed out of maintenance phase after 16.4.2 was
> tagged in November of last year. The stable/train branch is where
> Cinder's 15.x releases were made and has been out of official
> maintenance since 15.6.0 last May. The stable/victoria branch
> (Cinder 17.x releases) is the oldest still officially maintained and
> is slated to be dropped from maintenance next month.
> 

Everything Jeremy says is correct.  I would like to add a few points:

(1) With train in extended maintenance mode, appropriate backports are 
accepted, but no releases are made.  Thus, even if the patch were 
accepted, you would have to make other arrangements to get the code to 
your customers, as there will never be a train-series OpenStack release 
containing your patch.

(2) Backports are described in this cinder document, which also 
references the OpenStack Stable Branch Policy:
   https://docs.openstack.org/cinder/latest/contributor/backporting.html
The key issue here is that patches proposed directly to a stable branch 
are only accepted when the issue is not present in more recent branches 
(for example, Block Storage API v2 was removed in xena, so a bug 
affecting only the v2 API could be proposed directly to stable/wallaby). 
  This is not the case here (see next point).

(3) The Cinder project has traditionally considered a new backend driver 
to be a new feature, and hence not backportable.  This includes the 
restoration of drivers that have been kicked out of tree due to a lack 
of compliance with the CI policy.  The policy and why we have it is 
explained here:
   https://docs.openstack.org/cinder/latest/drivers-all-about.html
So, even if you were to propose your driver for the current release, it 
would not be backportable to earlier stable branches.  (Some people have 
maintained that since drivers are isolated to particular backends, maybe 
this restriction could be relaxed.  I'm willing to hear opinions about 
that idea (misguided though it may be), but even so, that's not the case 
here; you're proposing to add a new feature directly to a stable branch.)

(4) If you would like your driver included in the next OpenStack release 
(Zed), you need to propose it to master (which is currently the Zed 
development branch) before Milestone-2, as documented here:
   https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver
A necessary condition for your driver being included in the Zed release 
is that your third-party CI must be compliant with the CI policy 
referenced above in point #3.  (For some reason, people consistently 
underestimate the effort required to get a third-party CI running 
reliably, so I encourage you to begin working on that immediately.)

(5) It seems that your goal here is ultimately that your driver be 
included in the Red Hat OpenStack Platform 16 distribution, which is 
based on OpenStack Train.  Downstream distributions of OpenStack have 
their own policies about what code they will accept and distribute.  I 
know a little about RHOSP, and one of their requirements is that the 
code must exist in an appropriate upstream branch.  Given that you are 
proposing a new driver, the appropriate branch is master (since our 
upstream policies won't allow you to put your code anywhere else). 
Thus, even if your ultimate goal is a presence in RHOSP 16, the correct 
branch to which to contribute your driver is the current master branch.


Thus, speaking on behalf of the Cinder community in my final week as 
Cinder PTL, your request to contribute the DataCore driver directly to 
stable/train is denied.  I do encourage you to persist in your efforts 
to contribute it for the Zed release, as it would be nice to have 
DataCore back in the Cinder family.

cheers,
brian