<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 8, 2015 at 5:01 PM, Walter A. Boring IV <span dir="ltr"><<a href="mailto:walter.boring@hp.com" target="_blank">walter.boring@hp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Tony,<br>
This has been a long running pain point/problem for some of the drivers in Cinder.<br>
As a reviewer, I try and -1 drivers that talk directly to the database as I don't think<br>
drivers *should* be doing that. But, for some drivers, unfortunately, in order to<br>
implement the features, they currently need to talk to the DB. :( One of the new<br>
features in Cinder, namely consistency groups, has a bug that basically requires<br>
drivers to talk to the DB to fetch additional data. There are plans to remedy this<br>
problem in the M release of Cinder. For other DB calls in drivers, it's a case by<br>
case basis for removing the call, that's not entirely obvious how to do it at the<br>
current time. It's a topic that has come up now and again within the community,<br>
and I for one, would like to see the DB calls removed as well. Feel free to<br>
help contribute! It's OpenSource after all. :)<br>
<br>
Cheers,<br>
Walt<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Openstack/Cinder has a wealth of storage drivers to talk to different<br>
storage subsystems, which is great for users of openstack. However, it<br>
would be even greater if this same functionality could be leveraged<br>
outside of openstack/cinder. So that other projects don't need to<br>
duplicate the same functionality when trying to talk to hardware.<br>
<br>
<br>
When looking at cinder and asking around[1] about how one could<br>
potentially do this I find out that is there is quite a bit of coupling<br>
with openstack, like:<br>
<br>
* The NFS driver is initialized with knowledge about whether any volumes<br>
exist in the database or not, and if not, can trigger certain behavior<br>
to set permissions, etc. This means that something other than the<br>
cinder-volume service needs to mimic the right behavior if using this<br>
driver.<br>
<br>
* The LVM driver touches the database when creating a backup of a volume<br>
(many drivers do), and when managing a volume (importing an existing<br>
external LV to use as a Cinder volume).<br>
<br>
* A few drivers (GPFS, others?) touch the db when managing consistency<br>
groups.<br>
<br>
* EMC, Hitachi, and IBM NFS drivers touch the db when creating/deleting<br>
snapshots.<br>
<br>
<br>
Am I the only one that thinks this would be useful? What ideas do<br>
people have for making the cinder drivers stand alone, so that everyone<br>
could benefit from this great body of work?<br>
<br>
Thanks,<br>
Tony<br>
<br>
[1] Special thanks to Eric Harney for the examples of coupling<br>
<br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div></div>
.<br>
<br>
</blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:monospace,monospace">Hey Tony,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.<br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">John</div></div></div>