Open Stack

Actually, this is incorrect.

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.

What needs to happen is:
 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.

os-brick does all of the heavy lifting already on the host side of things.
The Connector API entry point:
https://github.com/openstack/os-brick/blob/master/os_brick/initiator/initiator_connector.py#L153

iSCSI example:
https://github.com/openstack/os-brick/blob/master/os_brick/initiator/connectors/iscsi.py#L370

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:
https://github.com/openstack/os-brick/blob/master/os_brick/initiator/linuxscsi.py#L375


Walt

On Sat, Apr 1, 2017 at 10:17 AM, Jay Bryant <jungleboyj at gmail.com> wrote:

> Matt,
>
> 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.
>
> Has doing that been solved since Tokyo?
>
> Jay
>
>
> On 4/1/2017 10:34 AM, Matt Riedemann wrote:
>
>> On 3/31/2017 8:55 PM, TommyLike Hu wrote:
>>
>>> There was a time when this feature had been both proposed in Cinder [1]
>>> and Nova [2], but unfortunately no one (correct me if I am wrong) is
>>> going to handle this feature during Pike. We do think extending an
>>> online volume is a beneficial and mostly supported by venders feature.
>>> We really don't want this feature missed from OpenStack and would like
>>> to continue on. So anyone could share your knowledge of how many works
>>> are left till now and  where should I start with?
>>>
>>> Thanks
>>> TommyLike.Hu
>>>
>>> [1] https://review.openstack.org/#/c/272524/
>>> [2]
>>> https://blueprints.launchpad.net/nova/+spec/nova-support-att
>>> ached-volume-extend
>>>
>>>
>>> __________________________________________________________________________
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> 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?
>>
>>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170403/7141cda2/attachment.html>