<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 15, 2016 at 6:21 PM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">In the nova-api meeting today we were talking about the nova os-assisted-volume-snapshots API and whether or not it was a proxy API to cinder. We determined it's not, it performs an action on a server resource. But what a few of us didn't realize was it's an admin API in nova only for cinder RemoteFSSnapDrivers to call when creating a volume snapshot.<br>
<br>
>From what I can tell, this is used in Cinder by the glusterfs, scality, quobyte and virtuozzo remotefs volume drivers.<br>
<br>
This is also a nova API that's only implemented for the libvirt compute driver - so gmann is going to document that in the nova api-ref for the API so it's at least communicated somewhere (it's not in the nova feature support matrix).<br>
<br>
The other thing I was wondering about was CI coverage. I looked through several cinder patches this morning looking for recent successful CI results for gluster/scality/quobyte but couldn't find any.<br>
<br>
Does someone have a link to a successful job run for one of those drivers? I'd like to see if they are testing volume snapshot and that it's properly calling the nova API and everything is working. Because this is also something that Nova could totally unknowingly break to that flow since we have no CI coverage for it (we don't have those cinder 3rd party CI jobs running against nova changes).<span class=""><font color="#888888"><br>
<br>
-- <br></font></span></blockquote><div> </div>Hi Matt,<div>I am in charge of the Scality CI. It used to report to changes in Cinder. A change in devstack broke us a couple of months ago, so I had to turn off my CI (because it was reporting false negative) while developing a patch. The patch took a long time to develop and merge but was merged finally: <a href="https://review.openstack.org/#/c/310204/">https://review.openstack.org/#/c/310204/</a></div><div><br></div><div>But in the mean time, something else crept in, hidden by the first failure. So the Scality CI is still broken, but it is my intention to find the commit that broke it and come up with a patch.</div><div><br></div><div>The C is still running on every change to Cinder, just that the result is not reported back. Results are here <a href="https://37.187.159.67:5443/job/cinder-sofs-validate/">https://37.187.159.67:5443/job/cinder-sofs-validate/</a> (yeah, that's an IP and with an invalid HTTPS certificate, I am not proud :p). This is the build artififact (logs) for a job that ran a couple of hours ago: <a href="https://37.187.159.67:5443/job/cinder-sofs-validate/17356/artifact/jenkins-logs/">https://37.187.159.67:5443/job/cinder-sofs-validate/17356/artifact/jenkins-logs/</a></div><div><br></div><div>So overall, I struggle to maintain that CI. Because I always have to play catch up. That's fine but what bother me is that when I finally come up with a patch (be it for Nova or Cinder) reviews take a long time because basically not a lot of people care/know about about os-assisted-volume-snapshots. </div><div><br></div><div>Cheers,<br>Jordan</div></div></div></div>

<br>
<a href="http://bit.ly/1VRgEAb" target="_blank"><img src="https://support.scality.com/Scality_RING6.png"></a>