In Denver, we agree to add a new "re-image" API in cinder to support upport
volume-backed server rebuild with a new image.
An initial blueprint has been drafted in [3], welcome to review it, thanks.
: )
The API is very simple, something like:
URL:
POST /v3/{project_id}/volumes/{volume_id}/action
Request body:
{
'os-reimage': {
'image_id': "71543ced-a8af-45b6-a5c4-a46282108a90"
}
}
The question is do we need a "force" parameter in request body? like:
{
'os-reimage': {
'image_id': "71543ced-a8af-45b6-a5c4-a46282108a90",
* 'force': True*
}
}
The "force" parameter idea comes from [4], means that
1. we can re-image an "available" volume directly.
2. we can't re-image "in-use"/"reserved" volume directly.
3. we can only re-image an "in-use"/"reserved" volume with "force"
parameter.
And it means nova need to always call re-image API with an extra "force"
parameter,
because the volume status is "in-use" or "reserve" when we rebuild the
server.
*So, what's you idea? Do we really want to add this "force" parameter?*
[1] https://etherpad.openstack.org/p/nova-ptg-stein L483
[2] https://etherpad.openstack.org/p/cinder-ptg-stein-thursday-rebuild L12
[3] https://review.openstack.org/#/c/605317
[4]
https://review.openstack.org/#/c/605317/1/specs/stein/add-volume-re-image-api.rst@75
Regards,
Yikun
----------------------------------------
Jiang Yikun（Kero）
Mail: yikunkero at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20181008/fb88c5ca/attachment-0001.html>