<div dir="ltr">Big +1 to what Brian said. In the current situation, the most sensible thing to do is to try to get the driver merged into Zed release (current master).<div>The release schedule for Zed is here[1] and you need to get the driver code merged before milestone 2 i.e. Jul 11 - Jul 15. Also the driver</div><div>requires a third party CI working to ensure the driver is working correctly so that also needs to be done at the same time.</div><div><br></div><div>I would recommend the DataCore driver developer team to join the Cinder PTG[2] as we are going to have sessions for driver maintainers</div><div>that would be very helpful to understand the process and how to contribute a new driver to Cinder.</div><div><br></div><div>[1] <a href="https://releases.openstack.org/zed/schedule.html">https://releases.openstack.org/zed/schedule.html</a></div><div>[2] <a href="https://etherpad.opendev.org/p/zed-ptg-cinder-planning">https://etherpad.opendev.org/p/zed-ptg-cinder-planning</a></div><div><br></div><div>Thanks and regards</div><div>Rajat Dhasmana</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 25, 2022 at 12:37 AM Sean Mooney <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 2022-03-24 at 13:26 -0400, Brian Rosmaita wrote:<br>
> On 3/24/22 10:53 AM, Jeremy Stanley wrote:<br>
> > [I'm leaving you in Cc since you don't seem to be subscribed to the<br>
> > mailing list.]<br>
> > <br>
> > On 2022-03-24 12:33:28 +0000 (+0000), Karthik Viswanath wrote:<br>
> > [...]<br>
> > > Given that this has direct revenue impact for DataCore and is time<br>
> > > sensitive, we request the community to approve our request to add<br>
> > > Cinder driver patch to 16.x maintenance releases ( mainly for<br>
> > > Trains branch).<br>
> > <br>
> > I can't speak for the Cinder maintainers and their backport<br>
> > policies, but from a release perspective there will be no further<br>
> > 16.x releases of Cinder. The stable/ussuri branch (where 16.x<br>
> > releases were made) passed out of maintenance phase after 16.4.2 was<br>
> > tagged in November of last year. The stable/train branch is where<br>
> > Cinder's 15.x releases were made and has been out of official<br>
> > maintenance since 15.6.0 last May. The stable/victoria branch<br>
> > (Cinder 17.x releases) is the oldest still officially maintained and<br>
> > is slated to be dropped from maintenance next month.<br>
> > <br>
> <br>
> Everything Jeremy says is correct.  I would like to add a few points:<br>
> <br>
> (1) With train in extended maintenance mode, appropriate backports are <br>
> accepted, but no releases are made.  Thus, even if the patch were <br>
> accepted, you would have to make other arrangements to get the code to <br>
> your customers, as there will never be a train-series OpenStack release <br>
> containing your patch.<br>
> <br>
> (2) Backports are described in this cinder document, which also <br>
> references the OpenStack Stable Branch Policy:<br>
>    <a href="https://docs.openstack.org/cinder/latest/contributor/backporting.html" rel="noreferrer" target="_blank">https://docs.openstack.org/cinder/latest/contributor/backporting.html</a><br>
> The key issue here is that patches proposed directly to a stable branch <br>
> are only accepted when the issue is not present in more recent branches <br>
> (for example, Block Storage API v2 was removed in xena, so a bug <br>
> affecting only the v2 API could be proposed directly to stable/wallaby). <br>
>   This is not the case here (see next point).<br>
> <br>
> (3) The Cinder project has traditionally considered a new backend driver <br>
> to be a new feature, and hence not backportable.  This includes the <br>
> restoration of drivers that have been kicked out of tree due to a lack <br>
> of compliance with the CI policy.  The policy and why we have it is <br>
> explained here:<br>
>    <a href="https://docs.openstack.org/cinder/latest/drivers-all-about.html" rel="noreferrer" target="_blank">https://docs.openstack.org/cinder/latest/drivers-all-about.html</a><br>
> So, even if you were to propose your driver for the current release, it <br>
> would not be backportable to earlier stable branches.  (Some people have <br>
> maintained that since drivers are isolated to particular backends, maybe <br>
> this restriction could be relaxed.  I'm willing to hear opinions about <br>
> that idea (misguided though it may be), but even so, that's not the case <br>
> here; you're proposing to add a new feature directly to a stable branch.)<br>
> <br>
> (4) If you would like your driver included in the next OpenStack release <br>
> (Zed), you need to propose it to master (which is currently the Zed <br>
> development branch) before Milestone-2, as documented here:<br>
>    <a href="https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver</a><br>
> A necessary condition for your driver being included in the Zed release <br>
> is that your third-party CI must be compliant with the CI policy <br>
> referenced above in point #3.  (For some reason, people consistently <br>
> underestimate the effort required to get a third-party CI running <br>
> reliably, so I encourage you to begin working on that immediately.)<br>
> <br>
> (5) It seems that your goal here is ultimately that your driver be <br>
> included in the Red Hat OpenStack Platform 16 distribution, which is <br>
> based on OpenStack Train.  Downstream distributions of OpenStack have <br>
> their own policies about what code they will accept and distribute.  I <br>
> know a little about RHOSP, and one of their requirements is that the <br>
> code must exist in an appropriate upstream branch.  Given that you are <br>
> proposing a new driver, the appropriate branch is master (since our <br>
> upstream policies won't allow you to put your code anywhere else). <br>
> Thus, even if your ultimate goal is a presence in RHOSP 16, the correct <br>
> branch to which to contribute your driver is the current master branch.<br>
on the downstream side for osp 16 you would also have to comply with the thrid party vender integration certification requirements<br>
<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/8.42/html/red_hat_openstack_certification_policy_guide/assembly-rhosp-certification-targets_rhosp-pol-introduction-policy-guide#con_products-implementing-openstack-apis_rhosp-pol-certification-targets" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/8.42/html/red_hat_openstack_certification_policy_guide/assembly-rhosp-certification-targets_rhosp-pol-introduction-policy-guide#con_products-implementing-openstack-apis_rhosp-pol-certification-targets</a><br>
to pass certification you will need to support installing your driver via tripleo/direct in adddiont to the other requirement in the document above.<br>
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<br>
phase in our old policy  <a href="https://access.redhat.com/support/policy/updates/openstack/platform" rel="noreferrer" target="_blank">https://access.redhat.com/support/policy/updates/openstack/platform</a> however there are explcit Third-party certification<br>
period listed for 16.1 and 16.2. <br>
<br>
the certification deadline for 16.2 is currently May 31, 2022<br>
while its not imposiable to complet certificaiton for 16.2 at this point downstream we still have ci and Recertification requiremtns<br>
<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/8.42/html/red_hat_openstack_certification_policy_guide/assembly-certification-lifecycle_rhosp-pol-certification-targets#con_continual-testing_rhosp-pol-certifiation-lifecycle" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/8.42/html/red_hat_openstack_certification_policy_guide/assembly-certification-lifecycle_rhosp-pol-certification-targets#con_continual-testing_rhosp-pol-certifiation-lifecycle</a><br>
the cinder specific requirement for certificaiton are listed here<br>
<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/8.42/html/red_hat_openstack_certification_policy_guide/con_cinder-subtests_rhosp-pol-openstack-director" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/8.42/html/red_hat_openstack_certification_policy_guide/con_cinder-subtests_rhosp-pol-openstack-director</a><br>
<br>
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<br>
paralle reach out to the redhat cerificaion team the workflow for certification is described here<br>
<a href="https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/8.42/html/red_hat_openstack_certification_workflow_guide/assembly-introduction-to-openstack-certification_rhosp-policy-guide" rel="noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/8.42/html/red_hat_openstack_certification_workflow_guide/assembly-introduction-to-openstack-certification_rhosp-policy-guide</a><br>
<br>
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.<br>
<br>
> <br>
> <br>
> Thus, speaking on behalf of the Cinder community in my final week as <br>
> Cinder PTL, your request to contribute the DataCore driver directly to <br>
> stable/train is denied.  I do encourage you to persist in your efforts <br>
> to contribute it for the Zed release, as it would be nice to have <br>
> DataCore back in the Cinder family.<br>
> <br>
> cheers,<br>
> brian<br>
> <br>
> <br>
<br>
<br>
</blockquote></div>