I had a look at the issues described in the etherpad, specifically the lack of feedback from Nova on the success of the resize.
This seems to be a problem not just for the NFS driver, since drivers using os-brick may fail [1], and Nova also handles extending of the LUKS structure of attached encrypted volumes, which may also fail.
So I believe it might be good idea to handle this as a separate bug.
The cleanest way to implement it would probably be to leave the volume status as "extending" for attached volumes, and use a new volume action, akin to the "os-migrate_volume_completion" action, to notify Cinder once Nova is done.
It might also be an option to just use the existing "os-reset_status" action to set the volume status to "error_extending" or back to "in-use", depending on whether something went wrong in Nova.
I had a look at the issues described in the etherpad, specifically the lack of feedback from Nova on the success of the resize.
This seems to be a problem not just for the NFS driver, since drivers using os-brick may fail [1], and Nova also handles extending of the LUKS structure of attached encrypted volumes, which may also fail.
So I believe it might be good idea to handle this as a separate bug. volume_ completion" action, to notify Cinder once Nova is done.
The cleanest way to implement it would probably be to leave the volume status as "extending" for attached volumes, and use a new volume action, akin to the "os-migrate_
It might also be an option to just use the existing "os-reset_status" action to set the volume status to "error_extending" or back to "in-use", depending on whether something went wrong in Nova.
[1]: https:/ /bugs.launchpad .net/cinder/ +bug/1849425