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. on the downstream side for osp 16 you would also have to comply with the thrid party vender integration certification requirements https://access.redhat.com/documentation/en-us/red_hat_openstack_certificatio... to pass certification you will need to support installing your driver via tripleo/direct in adddiont to the other requirement in the document above. also form a platform lifecycle point of view New certification are only allowed in the full support pahse and for the first 90 days fo maintance
On Thu, 2022-03-24 at 13:26 -0400, Brian Rosmaita wrote: phase in our old policy https://access.redhat.com/support/policy/updates/openstack/platform however there are explcit Third-party certification period listed for 16.1 and 16.2. the certification deadline for 16.2 is currently May 31, 2022 while its not imposiable to complet certificaiton for 16.2 at this point downstream we still have ci and Recertification requiremtns https://access.redhat.com/documentation/en-us/red_hat_openstack_certificatio... the cinder specific requirement for certificaiton are listed here https://access.redhat.com/documentation/en-us/red_hat_openstack_certificatio... as other have noted the best way forward is likely to work on getting datacore added back to master/zed with the required third party ci and in paralle reach out to the redhat cerificaion team the workflow for certification is described here https://access.redhat.com/documentation/en-us/red_hat_openstack_certificatio... i am neither involved in the storage side of osp rhosp or certification so im just providign the links to the downstream document to be helpful.
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