[cinder][drivers][stable-policy] propose adding DataCore driver to train
Hi OpenStack community,
I am the product manager for SANsymphony, a software defined SAN storage offering, at DataCorehttp://www.datacore.com/.
A little bit of history on the current request.
DataCore had a Cinder driver in Queen’s branch few years back. Due to organizational restructuring and change in priorities we had to scale back on our efforts towards OpenStack solutions. Because of this we were unable to be active in the community and as a result we got ousted out of Rocky branch due to lack of CI. Details herehttps://review.opendev.org/c/openstack/cinder/+/638029.
Currently we have multiple open opportunities with our European customers requiring us to certify RHOSP Cinder driver for both iSCSI and FC protocols. All our current customers are on RHOSP 16.x and would continue to be on that release for another 12-14 months. As a storage solutions provider, we will have to support our customers on 16.x release.
As per OpenStack’s Cinder driver policy, this change is considered as *new* driver request and we are unable to backport the changes directly.
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).
Thanks!
Karthik Viswanath Sr Product Manager, DataCore Cell: 9886032686
[https://www.datacoreassets.com/email-signatures/logo-email-signature.png]https://www.datacore.com/?utm_source=signature&utm_medium=email&utm_content=logo DataCore Software · The Authority on Software-Defined Storage 1901 Cypress Creek Road Ste. 200 Ft. Lauderdale, FL 33309
[cid1612899890*image002.png@01D83EF4.5833C600]
[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.
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
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_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 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
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@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_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 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
participants (5)
-
Brian Rosmaita
-
Jeremy Stanley
-
Karthik Viswanath
-
Rajat Dhasmana
-
Sean Mooney