When extending an attached Volume, Cinder will notify Nova after running the volume driver's extend_volume method, so that Nova can take steps to make the additional space available to the instance the volume is attached to.
Nova is notified using the external server event API [1], which is an asynchronous operation and has no effect on the volume status or the success of the extend.
For most drivers this is fine, but there are proposed changes to the NFS [2] and NetApp [3] drivers that rely on Nova to perform the actual resize if the volume is attached.
A failure to resize by Nova would then lead to an inconsistent volume status and size, because currently both are set before Nova even gets notified of the resize.
Lucio Seki, who first worked on [2] and [3], collected some thoughts on this in an etherpad [4]
together with other potential issues of the changes.
As I see it, there are two approaches to fixing this:
1. Have Cinder poll Nova for the completion.
Might require [5] to get fixed, to make resize failures show up in the instance action log.
Cinder would then poll the actions log of the instance to get the status of the operation and
update the volume status accordingly.
2. Have Nova call back into Cinder when the resize is finished.
The "os-reset_status" volume action could perhaps be abused for this, but a cleaner solution
would be the introduction of a new volume action, akin to "os-migrate_volume_completion".
I believe a new volume action would be the best way to implement this, and I would like to work on this, with the goal of getting [2] and [3] merged eventually.
I'm new to Cinder development though, so I am very happy about any suggestions or feedback.
When extending an attached Volume, Cinder will notify Nova after running the volume driver's extend_volume method, so that Nova can take steps to make the additional space available to the instance the volume is attached to.
Nova is notified using the external server event API [1], which is an asynchronous operation and has no effect on the volume status or the success of the extend.
For most drivers this is fine, but there are proposed changes to the NFS [2] and NetApp [3] drivers that rely on Nova to perform the actual resize if the volume is attached.
A failure to resize by Nova would then lead to an inconsistent volume status and size, because currently both are set before Nova even gets notified of the resize.
Lucio Seki, who first worked on [2] and [3], collected some thoughts on this in an etherpad [4]
together with other potential issues of the changes.
As I see it, there are two approaches to fixing this:
1. Have Cinder poll Nova for the completion.
Might require [5] to get fixed, to make resize failures show up in the instance action log.
Cinder would then poll the actions log of the instance to get the status of the operation and
update the volume status accordingly.
2. Have Nova call back into Cinder when the resize is finished. volume_ completion" .
The "os-reset_status" volume action could perhaps be abused for this, but a cleaner solution
would be the introduction of a new volume action, akin to "os-migrate_
I believe a new volume action would be the best way to implement this, and I would like to work on this, with the goal of getting [2] and [3] merged eventually.
I'm new to Cinder development though, so I am very happy about any suggestions or feedback.
[1]: https:/ /docs.openstack .org/api- ref/compute/ ?expanded= run-events- detail# run-events /review. opendev. org/c/openstack /cinder/ +/739079 /review. opendev. org/c/openstack /cinder/ +/820578 /etherpad. opendev. org/p/fix- nfs-online- extend /review. opendev. org/c/openstack /nova/+ /680648/
[2]: https:/
[3]: https:/
[4]: https:/
[5]: https:/