[openstack-dev] [cinder] Using storage drivers outside of openstack/cinder
John Griffith
john.griffith8 at gmail.com
Wed Sep 9 00:32:58 UTC 2015
On Tue, Sep 8, 2015 at 5:01 PM, Walter A. Boring IV <walter.boring at hp.com>
wrote:
> Hey Tony,
> This has been a long running pain point/problem for some of the drivers
> in Cinder.
> As a reviewer, I try and -1 drivers that talk directly to the database as
> I don't think
> drivers *should* be doing that. But, for some drivers, unfortunately, in
> order to
> implement the features, they currently need to talk to the DB. :( One of
> the new
> features in Cinder, namely consistency groups, has a bug that basically
> requires
> drivers to talk to the DB to fetch additional data. There are plans to
> remedy this
> problem in the M release of Cinder. For other DB calls in drivers, it's
> a case by
> case basis for removing the call, that's not entirely obvious how to do it
> at the
> current time. It's a topic that has come up now and again within the
> community,
> and I for one, would like to see the DB calls removed as well. Feel free to
> help contribute! It's OpenSource after all. :)
>
> Cheers,
> Walt
>
>> Openstack/Cinder has a wealth of storage drivers to talk to different
>> storage subsystems, which is great for users of openstack. However, it
>> would be even greater if this same functionality could be leveraged
>> outside of openstack/cinder. So that other projects don't need to
>> duplicate the same functionality when trying to talk to hardware.
>>
>>
>> When looking at cinder and asking around[1] about how one could
>> potentially do this I find out that is there is quite a bit of coupling
>> with openstack, like:
>>
>> * The NFS driver is initialized with knowledge about whether any volumes
>> exist in the database or not, and if not, can trigger certain behavior
>> to set permissions, etc. This means that something other than the
>> cinder-volume service needs to mimic the right behavior if using this
>> driver.
>>
>> * The LVM driver touches the database when creating a backup of a volume
>> (many drivers do), and when managing a volume (importing an existing
>> external LV to use as a Cinder volume).
>>
>> * A few drivers (GPFS, others?) touch the db when managing consistency
>> groups.
>>
>> * EMC, Hitachi, and IBM NFS drivers touch the db when creating/deleting
>> snapshots.
>>
>>
>> Am I the only one that thinks this would be useful? What ideas do
>> people have for making the cinder drivers stand alone, so that everyone
>> could benefit from this great body of work?
>>
>> Thanks,
>> Tony
>>
>> [1] Special thanks to Eric Harney for the examples of coupling
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> .
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
Hey Tony,
Thanks for posting this, I've thought for a while that something like what
you propose would be AWESOME and in fact is the direction we should go.
Initially I'd planned to make Cinder a consumable service outside of
OpenStack, but over time that's become less easy of a task with all the
libraries, dependencies and assumptions that we make with respect to our
environment.
The idea of a more "general" driver that can be consumed is something
that's come up a number of times and proposed to sit in Cinder as a driver
(Vipr/CoprHd and some others over the years), I think we (Cinder) could
provide that level of abstraction and consumability better than most of
what's been proposed so far. It would be a good deal of work I think to
make it happen and require some buy in / commitment from almost all the
Cinder contributors but I think it would be something worth doing.
I'll be curious to see if any other interest is expressed here. There are
ways to deal with the DB pieces and things like that I think (hackish ways
like config settings for OpenStack vs non-OpenStack env). Anyway, I'd love
to talk more about it... maybe in Tokyo?
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150908/aa85aa25/attachment.html>
More information about the OpenStack-dev
mailing list