Re: [openstack-dev] [cinder] Target classes in Cinder

2017-06-09 Thread Walter Boring
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

Re: [openstack-dev] [cinder] Target classes in Cinder

2017-06-02 Thread John Griffith
On Fri, Jun 2, 2017 at 3:51 PM, Jay Bryant wrote: > 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

Re: [openstack-dev] [cinder] Target classes in Cinder

2017-06-02 Thread John Griffith
On Fri, Jun 2, 2017 at 3:11 PM, Eric Harney 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). > >

Re: [openstack-dev] [cinder] Target classes in Cinder

2017-06-02 Thread Jay Bryant
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

Re: [openstack-dev] [cinder] Target classes in Cinder

2017-06-02 Thread Eric Harney
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 >

Re: [openstack-dev] [cinder] Target classes in Cinder

2017-06-02 Thread Patrick East
On Fri, Jun 2, 2017 at 12: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

Re: [openstack-dev] [cinder] Target classes in Cinder

2017-06-02 Thread Clay Gerrard
On Fri, Jun 2, 2017 at 12:47 PM, John Griffith wrote: > > > 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. > Might be useful to enumerate those?

Re: [openstack-dev] [cinder] Target classes in Cinder

2017-06-02 Thread Kendall Nelson
I personally agree that the target classes route is a much cleaner and more efficient way of doing it. Also, that it doesn't make sense to have all the code duplication to support doing it both ways. If other people agree with that- maybe we can start with not taking new drivers that do it the