[openstack-dev] [cinder] Target classes in Cinder
jsbryant at electronicjungle.net
Fri Jun 2 21:51:49 UTC 2017
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?
On Fri, Jun 2, 2017 at 4:14 PM Eric Harney <eharney at redhat.com> 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
> > 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
> > 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
> > common, iscsi and FC), it would just be a config option for my driver,
> > 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
> > 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
> > 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
> > 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev