Since we have to rely on Nova to actually perform the volume resize, we need to transform the external server event that notifies Nova of the resize into a synchronous operation that returns information on the success of the resize.
Introducing a new callback into Cinder to be called from Nova does accomplish this, but has a number of drawbacks.
For example, the external server event API only has a single field for event-specific data, in this case holding the ID of the volume. The new size of the volume would need to be either set in the database before the actual resize, which I would like to avoid, or put into the volumes admin metadata for Nova to access, which is not a clean solution either.
Another problem is how to deal with the case of the callback never arriving (e.g. caused by a network error). It would be difficult to implement a timeout with this design.
The much cleaner solution would be to replace the event with a new server action in the Nova API that can then be called synchronously by Cinder. This solves the mentioned Problems and is also semantically closer to what we actually want to do.
So I am going to focus now on introducing a new admin server action to Nova for extending attached volumes, that can be used by Cinder to trigger the operation and get feedback on its success.
Since we have to rely on Nova to actually perform the volume resize, we need to transform the external server event that notifies Nova of the resize into a synchronous operation that returns information on the success of the resize.
Introducing a new callback into Cinder to be called from Nova does accomplish this, but has a number of drawbacks.
For example, the external server event API only has a single field for event-specific data, in this case holding the ID of the volume. The new size of the volume would need to be either set in the database before the actual resize, which I would like to avoid, or put into the volumes admin metadata for Nova to access, which is not a clean solution either.
Another problem is how to deal with the case of the callback never arriving (e.g. caused by a network error). It would be difficult to implement a timeout with this design.
The much cleaner solution would be to replace the event with a new server action in the Nova API that can then be called synchronously by Cinder. This solves the mentioned Problems and is also semantically closer to what we actually want to do.
So I am going to focus now on introducing a new admin server action to Nova for extending attached volumes, that can be used by Cinder to trigger the operation and get feedback on its success.