<div dir="ltr">Actually, this is incorrect. <div><br></div><div>The sticking point of this all was doing the coordination and initiation of workflow from Nova. Cinder already has the ability to call the driver to do the resize of the volume. Cinder just prevents this now, because there is work that has to be done on the attached side to make the new size actually show up.</div><div><br></div><div>What needs to happen is:</div><div> A new Nova API needs to be created to initiate and coordinate this effort. The API would call Cinder to extend the size, then get the connection information from Cinder for that volume, then call os-brick to extend the size, then update the domain xml to tell libvirt to extend the size. The end user inside the VM would have to issue the same SCSI bus rescan and refresh that happens inside of os-brick, to make the kernel and filesystem in the VM recognize the new size. </div><div><br></div><div>os-brick does all of the heavy lifting already on the host side of things.</div><div>The Connector API entry point:</div><div><a href="https://github.com/openstack/os-brick/blob/master/os_brick/initiator/initiator_connector.py#L153">https://github.com/openstack/os-brick/blob/master/os_brick/initiator/initiator_connector.py#L153</a><br><br>iSCSI example:</div><div><a href="https://github.com/openstack/os-brick/blob/master/os_brick/initiator/connectors/iscsi.py#L370">https://github.com/openstack/os-brick/blob/master/os_brick/initiator/connectors/iscsi.py#L370</a><br><br>os-brick's code works for single path and multipath attached volumes. multipath has a bunch of added complexity with resize that should already be taken care of here:</div><div><a href="https://github.com/openstack/os-brick/blob/master/os_brick/initiator/linuxscsi.py#L375">https://github.com/openstack/os-brick/blob/master/os_brick/initiator/linuxscsi.py#L375</a><br><br><br>Walt</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 1, 2017 at 10:17 AM, Jay Bryant <span dir="ltr"><<a href="mailto:jungleboyj@gmail.com" target="_blank">jungleboyj@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Matt,<br>
<br>
I think discussion on this goes all the way back to Tokyo. There was work on the Cinder side to send the notification to Nova which I believe all the pieces were in place for. The missing part (sticking point) was doing a rescan of the SCSI bus in the node that had the extended volume attached.<br>
<br>
Has doing that been solved since Tokyo?<span class="HOEnZb"><font color="#888888"><br>
<br>
Jay</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 4/1/2017 10:34 AM, Matt Riedemann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 3/31/2017 8:55 PM, TommyLike Hu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There was a time when this feature had been both proposed in Cinder [1]<br>
and Nova [2], but unfortunately no one (correct me if I am wrong) is<br>
going to handle this feature during Pike. We do think extending an<br>
online volume is a beneficial and mostly supported by venders feature.<br>
We really don't want this feature missed from OpenStack and would like<br>
to continue on. So anyone could share your knowledge of how many works<br>
are left till now and where should I start with?<br>
<br>
Thanks<br>
TommyLike.Hu<br>
<br>
[1] <a href="https://review.openstack.org/#/c/272524/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/272524/</a><br>
[2]<br>
<a href="https://blueprints.launchpad.net/nova/+spec/nova-support-attached-volume-extend" rel="noreferrer" target="_blank">https://blueprints.launchpad.n<wbr>et/nova/+spec/nova-support-att<wbr>ached-volume-extend</a> <br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________ <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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</blockquote>
<br>
The nova blueprint description does not contain much for details, but from what is there it sounds a lot of like the existing volume swap operation which is triggered from Cinder by a volume migration or retype operation. How do those existing operations not already solve this use case?<br>
<br>
</blockquote>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div>