<div dir="ltr">I had initially looked into this for the 3PAR drivers when we initially were working on the target driver code.   The problem I found was, it would take a fair amount of time to refactor the code, with marginal benefit.   Yes, the design is better, but I couldn't justify the refactoring time, effort and testing of the new driver model just to get the same functionality.   Also, we would still need 2 CIs to ensure that the FC vs. iSCSI target drivers for 3PAR would work correctly, so it doesn't really save CI efforts much.   I guess what I'm trying to say is that, even though it's a better model, we always have to weigh the time investment to reward, and I couldn't justify it with all the other efforts I was involved with at the time.<div><br></div><div>I kind of assume that for the most part, most developers don't even understand why we have the target driver model, and secondly if they were educated on it, that they'd run into the same issue I had.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 2, 2017 at 12:47 PM, John Griffith <span dir="ltr"><<a href="mailto:john.griffith8@gmail.com" target="_blank">john.griffith8@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Hey Everyone,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">So quite a while back we introduced a new model for dealing with target management in the drivers (ie initialize_connection, ensure_export etc). </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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).</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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). </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Thanks,</div><div class="gmail_default" style="font-family:monospace,monospace">John</div></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div>