I had forgotten that we added this and am guessing that other cores did as well. As a result, it likely, was not enforced in driver reviews.
I need to better understand the benefit. In don't think there is a hurry to remove this right now. Can we put it on the agenda for Denver? Jay On Fri, Jun 2, 2017 at 4:14 PM Eric Harney <[email protected]> wrote: > On 06/02/2017 03:47 PM, John Griffith wrote: > > Hey Everyone, > > > > So quite a while back we introduced a new model for dealing with target > > management in the drivers (ie initialize_connection, ensure_export etc). > > > > Just to summarize a bit: The original model was that all of the target > > related stuff lived in a base class of the base drivers. Folks would > > inherit from said base class and off they'd go. This wasn't very > flexible, > > and it's why we ended up with things like two drivers per backend in the > > case of FibreChannel support. So instead of just say having > "driver-foo", > > we ended up with "driver-foo-iscsi" and "driver-foo-fc", each with their > > own CI, configs etc. Kind of annoying. > > We'd need separate CI jobs for the different target classes too. > > > > So we introduced this new model for targets, independent connectors or > > fabrics so to speak that live in `cinder/volume/targets`. The idea being > > that drivers were no longer locked in to inheriting from a base class to > > get the transport layer they wanted, but instead, the targets class was > > decoupled, and your driver could just instantiate whichever type they > > needed and use it. This was great in theory for folks like me that if I > > ever did FC, rather than create a second driver (the pattern of 3 > classes: > > common, iscsi and FC), it would just be a config option for my driver, > and > > I'd use the one you selected in config (or both). > > > > Anyway, I won't go too far into the details around the concept (unless > > somebody wants to hear more), but the reality is it's been a couple years > > now and currently it looks like there are a total of 4 out of the 80+ > > drivers in Cinder using this design, blockdevice, solidfire, lvm and drbd > > (and I implemented 3 of them I think... so that's not good). > > > > What I'm wondering is, even though I certainly think this is a FAR > SUPERIOR > > design to what we had, I don't like having both code-paths and designs in > > the code base. Should we consider reverting the drivers that are using > the > > new model back and remove cinder/volume/targets? Or should we start > > flagging those new drivers that don't use the new model during review? > > Also, what about the legacy/burden of all the other drivers that are > > already in place? > > > > Like I said, I'm biased and I think the new approach is much better in a > > number of ways, but that's a different debate. I'd be curious to see > what > > others think and what might be the best way to move forward. > > > > Thanks, > > John > > > > Some perspective from my side here: before reading this mail, I had a > bit different idea of what the target_drivers were actually for. > > The LVM, block_device, and DRBD drivers use this target_driver system > because they manage "local" storage and then layer an iSCSI target on > top of it. (scsi-target-utils, or LIO, etc.) This makes sense from the > original POV of the LVM driver, which was doing this to work on multiple > different distributions that had to pick scsi-target-utils or LIO to > function at all. The important detail here is that the > scsi-target-utils/LIO code could also then be applied to different > volume drivers. > > The Solidfire driver is doing something different here, and using the > target_driver classes as an interface upon which it defines its own > target driver. In this case, this splits up the code within the driver > itself, but doesn't enable plugging in other target drivers to the > Solidfire driver. So the fact that it's tied to this defined > target_driver class interface doesn't change much. > > The question, I think, mostly comes down to whether you get better code, > or better deployment configurability, by a) defining a few target > classes for your driver or b) defining a few volume driver classes for > your driver. (See coprhd or Pure for some examples.) > > I'm not convinced there is any difference in the outcome, so I can't see > why we would enforce any policy around this. The main difference is in > which cinder.conf fields you set during deployment, the rest pretty much > ends up the same in either scheme. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
