Open Stack

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).
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
requires a third party CI working to ensure the driver is working correctly
so that also needs to be done at the same time.

I would recommend the DataCore driver developer team to join the Cinder
PTG[2] as we are going to have sessions for driver maintainers
that would be very helpful to understand the process and how to contribute
a new driver to Cinder.

[1] https://releases.openstack.org/zed/schedule.html
[2] https://etherpad.opendev.org/p/zed-ptg-cinder-planning

Thanks and regards
Rajat Dhasmana

On Fri, Mar 25, 2022 at 12:37 AM Sean Mooney <smooney at redhat.com> wrote:

> On Thu, 2022-03-24 at 13:26 -0400, Brian Rosmaita wrote:
> > 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_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
> 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
> 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_certification/8.42/html/red_hat_openstack_certification_policy_guide/assembly-certification-lifecycle_rhosp-pol-certification-targets#con_continual-testing_rhosp-pol-certifiation-lifecycle
> the cinder specific requirement for certificaiton are listed here
>
> 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
>
> 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_certification/8.42/html/red_hat_openstack_certification_workflow_guide/assembly-introduction-to-openstack-certification_rhosp-policy-guide
>
> 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
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220325/dac500e5/attachment.htm>