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 <[email protected]
<mailto:[email protected]>> 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:
[email protected]?subject:unsubscribe
<http://[email protected]?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:
[email protected]?subject:unsubscribe
<http://[email protected]?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:[email protected]?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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
