Open Stack

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: yikunkero at gmail.com
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev