<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 27, 2018 at 8:44 AM Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 7/16/2018 4:20 AM, Gorka Eguileor wrote:<br>
> If I remember correctly the driver was deprecated because it had no<br>
> maintainer or CI. In Cinder we require our drivers to have both,<br>
> otherwise we can't guarantee that they actually work or that anyone will<br>
> fix it if it gets broken.<br>
<br>
Would this really require 3rd party CI if it's just local block storage <br>
on the compute node (in devstack)? We could do that with an upstream CI <br>
job right? We already have upstream CI jobs for things like rbd and nfs. <br>
The 3rd party CI requirements generally are for proprietary storage <br>
backends.<br>
<br>
I'm only asking about the CI side of this, the other notes from Sean <br>
about tweaking the LVM volume backend and feature parity are good <br>
reasons for removal of the unmaintained driver.<br>
<br>
Another option is using the nova + libvirt + lvm image backend for local <br>
(to the VM) ephemeral disk:<br>
<br>
<a href="https://github.com/openstack/nova/blob/6be7f7248fb1c2bbb890a0a48a424e205e173c9c/nova/virt/libvirt/imagebackend.py#L653" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/6be7f7248fb1c2bbb890a0a48a424e205e173c9c/nova/virt/libvirt/imagebackend.py#L653</a><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<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></blockquote><div><br></div><div class="gmail_default" style="font-family:monospace,monospace">We've had this conversation multiple times, here were the results from past conversations and the reasons we deprecated:</div><div class="gmail_default" style="font-family:monospace,monospace">1. Driver was not being tested at all (no CI, no upstream tests etc)</div><div class="gmail_default" style="font-family:monospace,monospace">2. We sent out numerous requests trying to determine if anybody was using the driver, didn't receive much feedback</div><div class="gmail_default" style="font-family:monospace,monospace">3. The driver didn't work for an entire release, this indicated that perhaps it wasn't that valuable</div><div class="gmail_default" style="font-family:monospace,monospace">4. The driver is unable to implement a number of the required features for a Cinder Block Device</div><div class="gmail_default" style="font-family:monospace,monospace">5. Digging deeper into performance tests most comparisons were doing things like</div><div class="gmail_default" style="font-family:monospace,monospace"> a. Using the shared single nic that's used for all of the cluster communications (ie DB, APIs, Rabbit etc)</div><div class="gmail_default" style="font-family:monospace,monospace"> b. Misconfigured deployment, ie using a 1Gig Nic for iSCSI connections (also see above)</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">The decision was that raw-block was not by definition a "Cinder Device", and given that it wasn't really tested or</div><div class="gmail_default" style="font-family:monospace,monospace">maintained that it should be removed. LVM is actually quite good, we did some pretty extensive testing and even</div><div class="gmail_default" style="font-family:monospace,monospace">presented it as a session in Barcelona that showed perf within approximately 10%. I'm skeptical any time I see</div><div class="gmail_default" style="font-family:monospace,monospace">dramatic comparisons of 1/2 performance, but I could be completely wrong.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I would be much more interested in putting efforts towards trying to figure out why you have such a large perf</div><div class="gmail_default" style="font-family:monospace,monospace">delta and see if we can address that as opposed to trying to bring back and maintain a driver that only half</div><div class="gmail_default" style="font-family:monospace,monospace">works.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Or as Jay Pipes mentioned, don't use Cinder in your case.</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></div>