Open Stack

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170602/609b4def/attachment.html>