[openstack-dev] [cinder] Rebranded Volume Drivers
There are a couple of cases [1][2] I'm seeing where new Cinder volume drivers for Liberty are rebranding other volume drivers. This involves inheriting off another volume driver's class(es) and providing some config options to set the backend name, etc. Two problems: 1) There is a thought of no CI [3] is needed, since you're using another vendor's driver code which does have a CI. 2) IMO another way of satisfying a check mark of being OpenStack supported and disappearing from the community. What gain does OpenStack get from these kind of drivers? Discuss. [1] - https://review.openstack.org/#/c/187853/ [2] - https://review.openstack.org/#/c/187707/4 [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Rebranded Volume Drivers
Hi, We now have a working CI on below patches: https://review.openstack.org/#/c/187707/ https://review.openstack.org/#/c/187853/ @jgriffith: we will sure start to give back to community.Thanks for pointing this out. Regards Nikesh On Thu, Jun 4, 2015 at 1:46 PM, Alex Meade wrote: > Agreed, I'd also like to mention that rebranded arrays may differ slightly > in functionality as well so the CIs would need to run against a physical > rebranded device. These differences also justify the need for letting > rebranded drivers in. > > -Alex > > On Thu, Jun 4, 2015 at 4:41 PM, Mike Perez wrote: > >> Sounds like the community would like CI's regardless, and I agree. >> >> Just because the driver code works for one backend solution, doesn't >> mean it's going to work with some other. >> >> Lets continue with code reviews with these patches only if they have a >> CI reporting, unless someone has a compelling reason we should not let >> any rebranded drivers in. >> >> -- >> Mike Perez >> >> >> On Wed, Jun 3, 2015 at 10:32 AM, Mike Perez wrote: >> > There are a couple of cases [1][2] I'm seeing where new Cinder volume >> > drivers for Liberty are rebranding other volume drivers. This involves >> > inheriting off another volume driver's class(es) and providing some >> > config options to set the backend name, etc. >> > >> > Two problems: >> > >> > 1) There is a thought of no CI [3] is needed, since you're using >> > another vendor's driver code which does have a CI. >> > >> > 2) IMO another way of satisfying a check mark of being OpenStack >> > supported and disappearing from the community. >> > >> > What gain does OpenStack get from these kind of drivers? >> > >> > Discuss. >> > >> > [1] - https://review.openstack.org/#/c/187853/ >> > [2] - https://review.openstack.org/#/c/187707/4 >> > [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers >> > >> > -- >> > Mike Perez >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Rebranded Volume Drivers
On 06/03/2015 01:32 PM, Mike Perez wrote: > There are a couple of cases [1][2] I'm seeing where new Cinder volume > drivers for Liberty are rebranding other volume drivers. This involves > inheriting off another volume driver's class(es) and providing some > config options to set the backend name, etc. > > Two problems: > > 1) There is a thought of no CI [3] is needed, since you're using > another vendor's driver code which does have a CI. > > 2) IMO another way of satisfying a check mark of being OpenStack > supported and disappearing from the community. > > What gain does OpenStack get from these kind of drivers? To CI or not to CI? That is up to the cinder team to decide. Any CI account in gerrit needs to follow the infra requirements, anything else is up to the project to decide, in this case, cinder. Thanks Mike, Anita. > > Discuss. > > [1] - https://review.openstack.org/#/c/187853/ > [2] - https://review.openstack.org/#/c/187707/4 > [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers > > -- > Mike Perez > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Rebranded Volume Drivers
On Wed, Jun 3, 2015 at 11:32 AM, Mike Perez wrote: > There are a couple of cases [1][2] I'm seeing where new Cinder volume > drivers for Liberty are rebranding other volume drivers. This involves > inheriting off another volume driver's class(es) and providing some > config options to set the backend name, etc. > > Two problems: > > 1) There is a thought of no CI [3] is needed, since you're using > another vendor's driver code which does have a CI. > > 2) IMO another way of satisfying a check mark of being OpenStack > supported and disappearing from the community. > > What gain does OpenStack get from these kind of drivers? > > Discuss. > > [1] - https://review.openstack.org/#/c/187853/ > [2] - https://review.openstack.org/#/c/187707/4 > [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers > > -- > Mike Perez > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > This case is interesting mostly because it's the same contractor submitting the driver for all the related platforms. Frankly I find the whole rebranding annoying, but there's certainly nothing really wrong with it, and well... why not, it's Open Source. What I do find annoying is the lack of give back; so this particular contributor has submitted a few drivers thus far (SCST, DotHill and some others IIRC), and now has three more proposed. This would be great except I personally have spent a very significant amount of time with this person helping with development, CI and understanding OpenStack and Cinder. To date, I don't see that he's provided a single code review (good or bad) or contributed anything back other than to his specific venture. Anyway... I think your point was for input on the two questions: For item '1': I guess as silly as it seems they should probably have 3'rd party CI. There are firmware differences etc that may actually change behaviors, or things my diverge, or maybe their code is screwed up and the inheritance doesn't work (doubtful). Yes, it's just a business venture in this case (good or bad, not for me to decide). The fact is we don't discriminate or place a value on peoples contributions, and this shouldn't be any different. I think the best answer is "follow same process for any driver" and move on. This does point out that maybe OpenStack/Cinder has grown to a point where there are so many options and choices that it's time to think about changing some of the policies and ways we do things. In my opinion, OpenStack doesn't gain much in this particular case, which brings me back to; remove all drivers except the ref-impl and have them pip installable and on a certified list based on CI. Thanks, John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Rebranded Volume Drivers
I think having the rebranded drivers is fine (yay for effective code re-use, right?), but they shouldn't have any special treatment. I don't like the idea of having different categories of volume drivers where some require CI and some don't. As far as I know, in this specific case, they already have a CI system for the 'base' driver, it should be trivial to add tests for the other drivers too at this point. -Patrick On Wed, Jun 3, 2015 at 10:59 AM, John Griffith wrote: > > > On Wed, Jun 3, 2015 at 11:32 AM, Mike Perez wrote: > >> There are a couple of cases [1][2] I'm seeing where new Cinder volume >> drivers for Liberty are rebranding other volume drivers. This involves >> inheriting off another volume driver's class(es) and providing some >> config options to set the backend name, etc. >> >> Two problems: >> >> 1) There is a thought of no CI [3] is needed, since you're using >> another vendor's driver code which does have a CI. >> >> 2) IMO another way of satisfying a check mark of being OpenStack >> supported and disappearing from the community. >> >> What gain does OpenStack get from these kind of drivers? >> >> Discuss. >> >> [1] - https://review.openstack.org/#/c/187853/ >> [2] - https://review.openstack.org/#/c/187707/4 >> [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers >> >> -- >> Mike Perez >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > This case is interesting mostly because it's the same contractor > submitting the driver for all the related platforms. Frankly I find the > whole rebranding annoying, but there's certainly nothing really wrong with > it, and well... why not, it's Open Source. > > What I do find annoying is the lack of give back; so this particular > contributor has submitted a few drivers thus far (SCST, DotHill and some > others IIRC), and now has three more proposed. This would be great except I > personally have spent a very significant amount of time with this person > helping with development, CI and understanding OpenStack and Cinder. > > To date, I don't see that he's provided a single code review (good or bad) > or contributed anything back other than to his specific venture. > > Anyway... I think your point was for input on the two questions: > > For item '1': > I guess as silly as it seems they should probably have 3'rd party CI. > There are firmware differences etc that may actually change behaviors, or > things my diverge, or maybe their code is screwed up and the inheritance > doesn't work (doubtful). > > Yes, it's just a business venture in this case (good or bad, not for me to > decide). The fact is we don't discriminate or place a value on peoples > contributions, and this shouldn't be any different. I think the best > answer is "follow same process for any driver" and move on. This does > point out that maybe OpenStack/Cinder has grown to a point where there are > so many options and choices that it's time to think about changing some of > the policies and ways we do things. > > In my opinion, OpenStack doesn't gain much in this particular case, which > brings me back to; > remove all drivers except the ref-impl and have them pip installable and > on a certified list based on CI. > > Thanks, > John > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Rebranded Volume Drivers
On 06/03/2015 01:59 PM, John Griffith wrote: > On Wed, Jun 3, 2015 at 11:32 AM, Mike Perez wrote: > >> There are a couple of cases [1][2] I'm seeing where new Cinder volume >> drivers for Liberty are rebranding other volume drivers. This involves >> inheriting off another volume driver's class(es) and providing some >> config options to set the backend name, etc. >> >> Two problems: >> >> 1) There is a thought of no CI [3] is needed, since you're using >> another vendor's driver code which does have a CI. >> >> 2) IMO another way of satisfying a check mark of being OpenStack >> supported and disappearing from the community. >> >> What gain does OpenStack get from these kind of drivers? >> >> Discuss. >> >> [1] - https://review.openstack.org/#/c/187853/ >> [2] - https://review.openstack.org/#/c/187707/4 >> [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers >> >> -- >> Mike Perez >> > > This case is interesting mostly because it's the same contractor > submitting the driver for all the related platforms. Frankly I find the > whole rebranding annoying, but there's certainly nothing really wrong with > it, and well... why not, it's Open Source. > > What I do find annoying is the lack of give back; so this particular > contributor has submitted a few drivers thus far (SCST, DotHill and some > others IIRC), and now has three more proposed. This would be great except I > personally have spent a very significant amount of time with this person > helping with development, CI and understanding OpenStack and Cinder. > > To date, I don't see that he's provided a single code review (good or bad) > or contributed anything back other than to his specific venture. > > Anyway... I think your point was for input on the two questions: > > For item '1': > I guess as silly as it seems they should probably have 3'rd party CI. > There are firmware differences etc that may actually change behaviors, or > things my diverge, or maybe their code is screwed up and the inheritance > doesn't work (doubtful). Given that part of the case made for CI was "ensure that Cinder ships drivers that work", the case of backend behavior diverging over time from what originally worked with Cinder seems like a valid concern. We lose the ability to keep tabs on that for derived drivers without CI. > > Yes, it's just a business venture in this case (good or bad, not for me to > decide). The fact is we don't discriminate or place a value on peoples > contributions, and this shouldn't be any different. I think the best > answer is "follow same process for any driver" and move on. This does > point out that maybe OpenStack/Cinder has grown to a point where there are > so many options and choices that it's time to think about changing some of > the policies and ways we do things. > > In my opinion, OpenStack doesn't gain much in this particular case, which > brings me back to; > remove all drivers except the ref-impl and have them pip installable and on > a certified list based on CI. > > Thanks, > John > The other issue I see with not requiring CI for "derived" drivers is that, inevitably, small changes will be made to the driver code, and we will find ourselves having to sort out how much change can happen before CI is then required. I don't know how to define that in a way that would be useful as a general policy. Eric __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Rebranded Volume Drivers
> -Original Message- > From: Eric Harney [mailto:ehar...@redhat.com] > Sent: Wednesday, June 03, 2015 12:54 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [cinder] Rebranded Volume Drivers > > On 06/03/2015 01:59 PM, John Griffith wrote: > > On Wed, Jun 3, 2015 at 11:32 AM, Mike Perez wrote: > > > >> There are a couple of cases [1][2] I'm seeing where new Cinder volume > >> drivers for Liberty are rebranding other volume drivers. This > >> involves inheriting off another volume driver's class(es) and > >> providing some config options to set the backend name, etc. > >> > >> Two problems: > >> > >> 1) There is a thought of no CI [3] is needed, since you're using > >> another vendor's driver code which does have a CI. > >> > >> 2) IMO another way of satisfying a check mark of being OpenStack > >> supported and disappearing from the community. > >> > >> What gain does OpenStack get from these kind of drivers? > >> > >> Discuss. > >> > >> [1] - https://review.openstack.org/#/c/187853/ > >> [2] - https://review.openstack.org/#/c/187707/4 > >> [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers > >> > >> -- > >> Mike Perez > >> > > > > This case is interesting mostly because it's the same contractor > > submitting the driver for all the related platforms. Frankly I find > > the whole rebranding annoying, but there's certainly nothing really > > wrong with it, and well... why not, it's Open Source. > > > > What I do find annoying is the lack of give back; so this particular > > contributor has submitted a few drivers thus far (SCST, DotHill and > > some others IIRC), and now has three more proposed. This would be > > great except I personally have spent a very significant amount of time > > with this person helping with development, CI and understanding OpenStack > and Cinder. > > > > To date, I don't see that he's provided a single code review (good or > > bad) or contributed anything back other than to his specific venture. > > > > Anyway... I think your point was for input on the two questions: > > > > For item '1': > > I guess as silly as it seems they should probably have 3'rd party CI. > > There are firmware differences etc that may actually change behaviors, > > or things my diverge, or maybe their code is screwed up and the > > inheritance doesn't work (doubtful). > > Given that part of the case made for CI was "ensure that Cinder ships drivers > that work", the case of backend behavior diverging over time from what > originally worked with Cinder seems like a valid concern. We lose the > ability to > keep tabs on that for derived drivers without CI. > > > > > Yes, it's just a business venture in this case (good or bad, not for > > me to decide). The fact is we don't discriminate or place a value on > > peoples contributions, and this shouldn't be any different. I think > > the best answer is "follow same process for any driver" and move on. > > This does point out that maybe OpenStack/Cinder has grown to a point > > where there are so many options and choices that it's time to think > > about changing some of the policies and ways we do things. > > > > In my opinion, OpenStack doesn't gain much in this particular case, > > which brings me back to; remove all drivers except the ref-impl and > > have them pip installable and on a certified list based on CI. > > > > Thanks, > > John > > > > The other issue I see with not requiring CI for "derived" drivers is that, > inevitably, small changes will be made to the driver code, and we will find > ourselves having to sort out how much change can happen before CI is then > required. I don't know how to define that in a way that would be useful as a > general policy. > > Eric > I haven't been involved in this project too long, but I have learned that if you want a driver included, you need to provide a CI system. It's a very clearly documented requirement. I'm all for inheritance and re-use, but along with what Eric said, at some point the HW/FW in those also-supported/re-branded arrays may change and if it's not being tested, then who knows what kind of end-user experience will occur. I'd be surprised if someone standing up OpenStack with Lenovo Storage would be okay knowing that it's never been tested on actual HW. - Curt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Rebranded Volume Drivers
On 6/3/15 6:16 PM, Bruns, Curt E wrote: > > >> -Original Message- >> From: Eric Harney [mailto:ehar...@redhat.com] >> Sent: Wednesday, June 03, 2015 12:54 PM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [cinder] Rebranded Volume Drivers >> >> On 06/03/2015 01:59 PM, John Griffith wrote: >>> On Wed, Jun 3, 2015 at 11:32 AM, Mike Perez wrote: >>> >>>> There are a couple of cases [1][2] I'm seeing where new Cinder volume >>>> drivers for Liberty are rebranding other volume drivers. This >>>> involves inheriting off another volume driver's class(es) and >>>> providing some config options to set the backend name, etc. >>>> >>>> Two problems: >>>> >>>> 1) There is a thought of no CI [3] is needed, since you're using >>>> another vendor's driver code which does have a CI. >>>> >>>> 2) IMO another way of satisfying a check mark of being OpenStack >>>> supported and disappearing from the community. >>>> >>>> What gain does OpenStack get from these kind of drivers? >>>> >>>> Discuss. >>>> >>>> [1] - https://review.openstack.org/#/c/187853/ >>>> [2] - https://review.openstack.org/#/c/187707/4 >>>> [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers >>>> >>>> -- >>>> Mike Perez >>>> >>> >>> This case is interesting mostly because it's the same contractor >>> submitting the driver for all the related platforms. Frankly I find >>> the whole rebranding annoying, but there's certainly nothing really >>> wrong with it, and well... why not, it's Open Source. >>> >>> What I do find annoying is the lack of give back; so this particular >>> contributor has submitted a few drivers thus far (SCST, DotHill and >>> some others IIRC), and now has three more proposed. This would be >>> great except I personally have spent a very significant amount of time >>> with this person helping with development, CI and understanding OpenStack >> and Cinder. >>> >>> To date, I don't see that he's provided a single code review (good or >>> bad) or contributed anything back other than to his specific venture. >>> >>> Anyway... I think your point was for input on the two questions: >>> >>> For item '1': >>> I guess as silly as it seems they should probably have 3'rd party CI. >>> There are firmware differences etc that may actually change behaviors, >>> or things my diverge, or maybe their code is screwed up and the >>> inheritance doesn't work (doubtful). >> >> Given that part of the case made for CI was "ensure that Cinder ships drivers >> that work", the case of backend behavior diverging over time from what >> originally worked with Cinder seems like a valid concern. We lose the >> ability to >> keep tabs on that for derived drivers without CI. >> >>> >>> Yes, it's just a business venture in this case (good or bad, not for >>> me to decide). The fact is we don't discriminate or place a value on >>> peoples contributions, and this shouldn't be any different. I think >>> the best answer is "follow same process for any driver" and move on. >>> This does point out that maybe OpenStack/Cinder has grown to a point >>> where there are so many options and choices that it's time to think >>> about changing some of the policies and ways we do things. >>> >>> In my opinion, OpenStack doesn't gain much in this particular case, >>> which brings me back to; remove all drivers except the ref-impl and >>> have them pip installable and on a certified list based on CI. >>> >>> Thanks, >>> John >>> >> >> The other issue I see with not requiring CI for "derived" drivers is that, >> inevitably, small changes will be made to the driver code, and we will find >> ourselves having to sort out how much change can happen before CI is then >> required. I don't know how to define that in a way that would be useful as a >> general policy. >> >> Eric >> > > I haven't been involved in this project too long, but I have learned that if > you want a driver included, you need to provide a CI system. It's a very > clearly documented requirement. I'm al
Re: [openstack-dev] [cinder] Rebranded Volume Drivers
On 06/03/2015 02:53 PM, Eric Harney wrote: On 06/03/2015 01:59 PM, John Griffith wrote: On Wed, Jun 3, 2015 at 11:32 AM, Mike Perez wrote: There are a couple of cases [1][2] I'm seeing where new Cinder volume drivers for Liberty are rebranding other volume drivers. This involves inheriting off another volume driver's class(es) and providing some config options to set the backend name, etc. Two problems: 1) There is a thought of no CI [3] is needed, since you're using another vendor's driver code which does have a CI. 2) IMO another way of satisfying a check mark of being OpenStack supported and disappearing from the community. What gain does OpenStack get from these kind of drivers? Discuss. [1] - https://review.openstack.org/#/c/187853/ [2] - https://review.openstack.org/#/c/187707/4 [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers -- Mike Perez This case is interesting mostly because it's the same contractor submitting the driver for all the related platforms. Frankly I find the whole rebranding annoying, but there's certainly nothing really wrong with it, and well... why not, it's Open Source. What I do find annoying is the lack of give back; so this particular contributor has submitted a few drivers thus far (SCST, DotHill and some others IIRC), and now has three more proposed. This would be great except I personally have spent a very significant amount of time with this person helping with development, CI and understanding OpenStack and Cinder. To date, I don't see that he's provided a single code review (good or bad) or contributed anything back other than to his specific venture. Anyway... I think your point was for input on the two questions: For item '1': I guess as silly as it seems they should probably have 3'rd party CI. There are firmware differences etc that may actually change behaviors, or things my diverge, or maybe their code is screwed up and the inheritance doesn't work (doubtful). Given that part of the case made for CI was "ensure that Cinder ships drivers that work", the case of backend behavior diverging over time from what originally worked with Cinder seems like a valid concern. We lose the ability to keep tabs on that for derived drivers without CI. Yes, it's just a business venture in this case (good or bad, not for me to decide). The fact is we don't discriminate or place a value on peoples contributions, and this shouldn't be any different. I think the best answer is "follow same process for any driver" and move on. This does point out that maybe OpenStack/Cinder has grown to a point where there are so many options and choices that it's time to think about changing some of the policies and ways we do things. In my opinion, OpenStack doesn't gain much in this particular case, which brings me back to; remove all drivers except the ref-impl and have them pip installable and on a certified list based on CI. Thanks, John The other issue I see with not requiring CI for "derived" drivers is that, inevitably, small changes will be made to the driver code, and we will find ourselves having to sort out how much change can happen before CI is then required. I don't know how to define that in a way that would be useful as a general policy. Eric __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev At first I wasn't too sure that requiring an additional CI for a derived driver made sense. The concerns raised, however, are compelling and I think that a CI should be required for rebranded drivers. It is inevitable that subtle differences will sneak in and we need to have CI in place to catch any failures that may also be introduced. Jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Rebranded Volume Drivers
Sounds like the community would like CI's regardless, and I agree. Just because the driver code works for one backend solution, doesn't mean it's going to work with some other. Lets continue with code reviews with these patches only if they have a CI reporting, unless someone has a compelling reason we should not let any rebranded drivers in. -- Mike Perez On Wed, Jun 3, 2015 at 10:32 AM, Mike Perez wrote: > There are a couple of cases [1][2] I'm seeing where new Cinder volume > drivers for Liberty are rebranding other volume drivers. This involves > inheriting off another volume driver's class(es) and providing some > config options to set the backend name, etc. > > Two problems: > > 1) There is a thought of no CI [3] is needed, since you're using > another vendor's driver code which does have a CI. > > 2) IMO another way of satisfying a check mark of being OpenStack > supported and disappearing from the community. > > What gain does OpenStack get from these kind of drivers? > > Discuss. > > [1] - https://review.openstack.org/#/c/187853/ > [2] - https://review.openstack.org/#/c/187707/4 > [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers > > -- > Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Rebranded Volume Drivers
Agreed, I'd also like to mention that rebranded arrays may differ slightly in functionality as well so the CIs would need to run against a physical rebranded device. These differences also justify the need for letting rebranded drivers in. -Alex On Thu, Jun 4, 2015 at 4:41 PM, Mike Perez wrote: > Sounds like the community would like CI's regardless, and I agree. > > Just because the driver code works for one backend solution, doesn't > mean it's going to work with some other. > > Lets continue with code reviews with these patches only if they have a > CI reporting, unless someone has a compelling reason we should not let > any rebranded drivers in. > > -- > Mike Perez > > > On Wed, Jun 3, 2015 at 10:32 AM, Mike Perez wrote: > > There are a couple of cases [1][2] I'm seeing where new Cinder volume > > drivers for Liberty are rebranding other volume drivers. This involves > > inheriting off another volume driver's class(es) and providing some > > config options to set the backend name, etc. > > > > Two problems: > > > > 1) There is a thought of no CI [3] is needed, since you're using > > another vendor's driver code which does have a CI. > > > > 2) IMO another way of satisfying a check mark of being OpenStack > > supported and disappearing from the community. > > > > What gain does OpenStack get from these kind of drivers? > > > > Discuss. > > > > [1] - https://review.openstack.org/#/c/187853/ > > [2] - https://review.openstack.org/#/c/187707/4 > > [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers > > > > -- > > Mike Perez > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
