Open Stack

On Fri, Jun 2, 2017 at 12:47 PM, John Griffith <john.griffith8 at gmail.com>
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?  Perhaps drawing attention to the
benefits would spur some driver maintainers that haven't made the switch to
think they could leverage the work into something impactful?


> Should we consider reverting the drivers that are using the new model back
> and remove cinder/volume/targets?
>

Probably not anytime soon if it means dropping 76 of 80 drivers?  Or at
least that's a different discussion ;)


> Or should we start flagging those new drivers that don't use the new model
> during review?
>

Seems like a reasonable social construct to promote going forward - at
least it puts a tourniquet on it.  Perhaps there some intree development
documentation that could be updated to point people in the right direction
or some warnings that can be placed around the legacy patterns to keep
people for stumbling on bad examples?


> Also, what about the legacy/burden of all the other drivers that are
> already in place?
>
>
What indeed... but that's down the road right - for the moment it's just
figuring how to give things a bit of a kick in the pants?  Or maybe
admitting w/o a kick in the pants - living with the cruft is the plan of
record?

I'm curious to see how this goes, Swift has some plugin interfaces that
have been exposed through the ages and the one thing constant with
interface patterns is that the cruft builds up...

Good Luck!

-Clay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170602/8897905a/attachment.html>