[openstack-dev] [Cinder] [Nova] Extend attached volume

Jay S Bryant jungleboyj at gmail.com
Tue Apr 4 01:19:55 UTC 2017



On 4/3/2017 11:27 AM, Walter Boring wrote:
> 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 
> <mailto: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/
>             <https://review.openstack.org/#/c/272524/>
>             [2]
>             https://blueprints.launchpad.net/nova/+spec/nova-support-attached-volume-extend
>             <https://blueprints.launchpad.net/nova/+spec/nova-support-attached-volume-extend>
>
>
>
>             __________________________________________________________________________
>
>             OpenStack Development Mailing List (not for usage questions)
>             Unsubscribe:
>             OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>             <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>             http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>             <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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> __________________________________________________________________________
> 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
Walt,

Sorry for getting the info wrong.  Thank you for getting the right 
details out there!

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170403/c1f86caa/attachment.html>


More information about the OpenStack-dev mailing list