On 10/8/2018 8:54 AM, Sean McGinnis wrote:
On Mon, Oct 08, 2018 at 03:09:36PM +0800, Yikun Jiang wrote:
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.
: )
[snip]
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?*
I would prefer we have the "force" parameter, even if it is something that will
always be defaulted to True from Nova.
Having this exposed as a REST API means anyone could call it, not just Nova
code. So as protection from someone doing something that they are not really
clear on the full implications of, having a flag in there to guard volumes that
are already attached or reserved for shelved instances is worth the very minor
extra overhead.
I concur with Sean's assessment. I think putting a safety switch in
place in this design is important to ensure that people using the API
directly are less likely to do something that they may not actually want
to do.
Jay
[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: yikunk...@gmail.com
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
